Re: Question about ISO8601 vs. strftime()

On Sat, 23 Dec 2006 21:27:29 -0600, Ian Woods wrote
(in article <Xns98A32331FB75Cnewspub3atwuggydotor@xxxxxxxxxxxxxxx>):

So, my question is, with respect to ISO 8601, are both forms
valid? Or is the strftime() one actually correct, and a slew of
online references to ISO8601 just get it wrong? I don't have
official ISO 8601 documentation, just references to it via the
web.

I don't have a copy of the real ISO 8601 either. AFAIK, both the forms
with and without separators are allowed and equivalent. This certainly
seems to be the case from a number of sources including:

http://www.cl.cam.ac.uk/~mgk25/iso-time.html

Unless I missed something, that link only shows the form with the UTC
offset without the ':' separator. It shows regular time such as hh:mm,
but not the offset as far as I can tell.


http://en.wikipedia.org/wiki/ISO_8601 (looking at the "formats" on the
RHS)

Again, I don't see it used that way in the examples there for the UTC
offset value. BTW, I tried editing in a comment about the
inconsistencies between the wiki entry and the C99 standard
description, and it was summarily expunged within a few minutes. Makes
wiki suspect, when questions of technical accuracy are deleted, rather
than clarified, especially when it happens so quickly, and nothing is
said even on the discussion page.

http://hydracen.com/dx/iso8601.htm

This link definitely shows several forms for the UTC offset, including
the 'short form' I haven't seen before of hours only.

Since there are so many variations, it somewhat calls into question the
value of using such a loose standard, as it doesn't exactly make it
easier on the "consumer" of the data, which still has to know how to
interpret all the variations. Oh well, I guess I'll stick with this
specifier, which seems to match most platform utilities that attempt a
date at least similar to ISO8601:

"%Y-%m-%dT%H:%M:%S%z"

That said, people seem to dislike the "T" notation for the time
component, usually resulting in this variation being used instead:

"%Y-%m-%d %H:%M:%S%z"
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





.

Relevant Pages

  • Re: Question about ISO8601 vs. strftime()
    ... online references to ISO8601 just get it wrong? ... that link only shows the form with the UTC ... but not the offset as far as I can tell. ... assumed to be in some local time zone. ...
    (comp.programming)
  • Re: Strategies for time offsets
    ... There isn't a mechanism for a negative delta time within the quadword storage, though applications are certainly free to stuff a sign bit somewhere. ... The UTC format is often a better choice here, particularly when dealing with the storage of time values. ... And then, in the core of the program, I would simply need to do a LIB$ADD_TIMES and not have to worry about whether the offset is negative or positive. ... Barring cases where this timezone stuff is the bulk of the operation and there's nothing else around consuming more cycles or wallclock time -- I/O tends to be my go-to example here for massive overhead -- I'd tend to look to optimize this math stuff and any associated system call overhead later. ...
    (comp.os.vms)
  • Re: obtaining the time offset from UTC
    ... >> I need to find out the time difference between UTC and local time. ... >> saving and always returns local time zone offset. ... >> When daylight saving is not in effect, then the offset should be +1 hour. ...
    (comp.lang.c)
  • Re: how to make dates without timezones?
    ... the offset from UTC is the local ... clock offset, for the other it is zero regardless of location. ... UTC methods should be faster than local methods, ...
    (comp.lang.java.programmer)
  • Re: Newbie Q: How to program in UTC (time/calendar) ?
    ... I here fight with my intuition :-) ... parameter that defaults to 0 (UTC). ... to the default offset of 0. ... and converting it to the corresponding time for your computer's offset ...
    (comp.lang.ada)