Menu

#1996 clock scan weirdness on ISO 8601 times

obsolete: 8.4b1
closed-fixed
5
2004-08-19
2002-07-26
No

I (think I) observe 3 problems with "clock scan".

In the tcl8.4b1 release, the clock.n man page discusses
the
clock scan's ability to crack ISO 8601 point-in-time
formats.
The man page is incomplete, since it doesn't give
examples of
ISO 8601 formats using hyphens and colons, such as:
2002-07-15T20:15:00

Then, sitting here in the US PDT time zone (-7:00 from
UTC) if I do
clock format [ clock scan 2002-07-15T20:15:00 ]
I get
Mon Jul 15 06:15:00 PDT 2002
This is 2*7 hours off of reality; the value 7 is my UTC
delta.

Finally, clock scan can't handle the suffix time zone
qualifier, such as
2002-07-26T11:56:39-07:00
It throws an error "unable to convert"

I'm no expert in the tarpit of calendrics, and various
calendric
specifications as recommended by ISO or WWW or RFC.

Please see Tcl bug 218518 which was closed ~2years ago.
I don't think that the problems in 218518 were fully
fixed.

Discussion

  • Donal K. Fellows

    • labels: 105657 --> 06. Time Measurement
    • assigned_to: dkf --> kennykb
     
  • Kevin B KENNY

    Kevin B KENNY - 2004-08-19

    Logged In: YES
    user_id=99768

    The [clock scan] with a fixed format in 8.5 can crack
    most ISO8601 point-in-time formats; certainly, all the
    ones that are in common use. For instance,

    [clock scan 2002-07-15T20:15:00 \ -format %Y-%m-%dT%H:%M:%S]

    will do what is wanted, as will

    [clock scan 2002-07-15T20:15:00-07:00 \ -format %Y-%m-%dT%H:%M:%S%Z]

    I plan within the next few weeks to put code into
    tcllib to accept a string that is known to be an
    ISO8601 point-in-time and deduce its format for
    the new [clock scan]; this code, however, is
    much less urgent, since those exchanging ISO8601
    dates have normally agreed on the format in detail.

     
  • Kevin B KENNY

    Kevin B KENNY - 2004-08-19
    • status: open --> closed-fixed