Brooks Harris said:
>> ISO 8601 does not represent daylight saving nor time zones.
> It can represent both, but incompletely, or ambiguously. The "time
> element" called "zone designator" conflates "offset from UTC" and
> "Daylight Savings offset" in the "time element" called "zone designator".
Poul-Henning Kamp wrote:
>
> >However for events in the future (meetings etc.) you need to record a
> >time and a place, because the UTC offset and time zone rules are not
> >predictable.
>
> The main problem here is to get people to give you enough information
> in the first place.
>
> For instan
Brooks Harris said:
> In particular, 8601 implies use of "offset
> from UTC", as indication of "local time", but conflates this with
> Daylight Savings.
No, it doesn't.
It uses offset from UTC as an indication of, wait for it, offset from UTC.
> For example, a date and time in New York City mi
Brooks Harris wrote:
>
> > > Most explainations, and the spec itself, say that NTP does not account
> > > for Leap Seconds, and it does not, *explicitly*. Note, however, that
> > > 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap
> > > Seconds in effect at 1972-01-01T00:00:00Z (U
Brooks Harris said:
> An organization I work with has been using a web-based meeting
> scheduling calendar that gives meeting date-time notifications.
>
> Recently it has been announcing meetings as, for example -
>
> "When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00)
> Eastern
On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote:
In message , Tony F
inch writes:
However for events in the future (meetings etc.) you
need to record a time and a place, because the UTC offset and time zone
rules are not predictable.
The main problem here is to get people to give you
In message , Tony F
inch writes:
>However for events in the future (meetings etc.) you
>need to record a time and a place, because the UTC offset and time zone
>rules are not predictable.
The main problem here is to get people to give you enough information
in the first place.
For insta
Tony Finch said:
> However for events in the future (meetings etc.) you
> need to record a time and a place, because the UTC offset and time zone
> rules are not predictable.
More precisely, the accuracy of predictions varies.
(I'd have a lot of confidence in the 2005 offsets for England. Rather
Tony Finch wrote
> Right, and this is good for many purposes, e.g. recording times of events
now or in the past. However for events in the future (meetings etc.) you
need to record a time and a place, because the UTC offset and time zone
rules are not predictable.
Even better, local time can be u
Poul-Henning Kamp wrote:
> >> > > For example, a date and time in New York City might be represented
> >> > > as 2014-07-04T00:00:00-05:00 [...]
> >> >
> >> > The former is incorrect.
> >>
> >> Incorrect where?
> >
> >The UTC offset in New York at that time was not -05:00 so that cannot be a
> >t
10 matches
Mail list logo
