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.
Brooks Harris bro...@edlmax.com wrote:
Its important to note 8601 is silent on how Daylight Savings Time is handled
and provides no recommendation of how it might be indicated or represented.
ISO 8601 does not represent daylight saving nor time zones.
Looking closely you'll find there is no
In message alpine.lsu.2.00.1408271011340.23...@hermes-1.csi.cam.ac.uk, Tony F
inch writes:
Brooks Harris bro...@edlmax.com wrote:
Its important to note 8601 is silent on how Daylight Savings Time is
handled
and provides no recommendation of how it might be indicated or represented.
Hi Tony,
On 2014-08-27 05:22 AM, Tony Finch wrote:
Brooks Harris bro...@edlmax.com wrote:
Its important to note 8601 is silent on how Daylight Savings Time is handled
and provides no recommendation of how it might be indicated or represented.
ISO 8601 does not represent daylight saving nor
In message alpine.lsu.2.00.1408271650570.23...@hermes-1.csi.cam.ac.uk, Tony F
inch writes:
Brooks Harris bro...@edlmax.com 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?
Hi Tony,
On 2014-08-27 12:08 PM, Tony Finch wrote:
Brooks Harrisbro...@edlmax.com wrote:
On 2014-08-27 05:22 AM, Tony Finch wrote:
ISO 8601 does not represent daylight saving nor time zones.
It can represent both, but incompletely, or ambiguously. The time element
called zone designator
Gerard Ashton ashto...@comcast.net wrote:
For example, if one wishes to use the format 2014-08-24, is it mandatory
that the day begin at midnight according to some unspecified local time?
ISO 8601 does not specify the time zone alignment of calendar days. It
allows you to identify a date in
On Aug 26, 2014, at 4:43 AM, Tony Finch d...@dotat.at wrote:
Gerard Ashton ashto...@comcast.net wrote:
For example, if one wishes to use the format 2014-08-24, is it mandatory
that the day begin at midnight according to some unspecified local time?
ISO 8601 does not specify the time zone
Rob Seaman sea...@noao.edu wrote:
A date is an integer. A timestamp is a real. (however represented)
And this is a great example of why UTC is usually implemented incorrectly.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly
ISO 8601 is expensive; I obtained a copy before they started making it hard
to find copies on the web. The wording of the standard is convoluted. Does
anyone know if there is a highly-reputable, readable description of the
standard that explains the extent to which the various choices are
16 matches
Mail list logo
