Poul-Henning Kamp p...@phk.freebsd.dk 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
time in New
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
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
On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote:
In message alpine.lsu.2.00.1408281021260.23...@hermes-1.csi.cam.ac.uk, 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
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 Time
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 might be
Poul-Henning Kamp p...@phk.freebsd.dk 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.
