## Re: [ISO8601] Re: questions about time intervals

Expand Messages
• I am largely in agreement with all of that. Certainly the specifics of a mutual agreement trump an argument over what is most logical. In the absence of a
Message 1 of 35 , Aug 21, 2004
I am largely in agreement with all of that. Certainly the specifics of a mutual agreement trump an argument over what is most logical.  In the absence of a specific agreement on implied time, and in the absence of specific time, I just feel the whole range of possibilities has to be considered, and therefore the end time is logically the latest of all possibilities, and becomes a "no later than" the end of the specified day.

And, of course, if it really matters, incomplete representations shouldn't be used.

piebaldconsult <PIEBALDconsult@...> wrote:
No, they just define what a date (either calendar or ordinal) is.
Without saying what one means or how to use it.

But also look at 3.17 and 3.26 -- 3.26 defines a time-point, and 3.17
(and 5.5.4.1) specifies that the values in a start/end interval are
time-points (I think I mistyped it as 5.4.4.1 in my earlier post,
sorry)

And 3.23

And 4.1

And 5.5.3.1.a

And, of course, 5.5.5.d

I guess it boils down to this: a time interval with start and end
time-points with "reduced precision" (i.e. no time of day specified)
can only be used "by mutual agreement". It is perfectly valid and
possibly probable that the agreement will be that the start value
would be "T000000" and the end value be "T240000", as you argue. But
it doesn't have to be, another partnership could use "T090000"
and "T170000" respectively as their time of day values.

I myself would demand with any and all who wish to interchange with
me, that "reduced precision" _never_ be used. The computer doesn't
care and I think network speeds are sufficiently high that sending
those "extra" bytes won't matter a gnat's arse.

Allow me to point out that I doubt your nominal meeting will convene
at midnight one one day and run through to midnight on another day.
It seems likely you would hold it from 090000 to 170000 on each day,
meaning you would need to send a time interval format for _each_ of
the meeting periods.