> > OK. I'll need to generalize the current code, which looks specifically
> > for "gmt". Possibly, we'll have just the "GMT+/-####" case handled for
> > 7.0, but if I get time.
> I believe it should preferrably be called "UTC".
The specific case we are solving is an interaction with the zinc
timezone database available on (at least) Linux and FreeBSD. Both
platforms have "GMT+/-n" zones defined, and we'll want to correctly
parse them.
> > And we'll allow a superset of the Posix standard, so "GMT+0800" will
> He mentioned earlier that it has to be GMT+08:00 or GMT+8.
Right. That's why I thought I'd mention that we'll do a superset.
> > be legal (otherwise, it would disallow the ISO8601 standard which imho
> > should take precedence).
> Oh please, it should. Is it just me or is this notation not making any
> sense? If GMT+08:00 means "you need to add 8 hours to your local time zone
> to get to GMT", then x = a + b means "you need to add 'b' to 'x' in order
> to get 'a'". Darn standards. How about NOON+01:30 to indicate 10:30(am)?
Not in this lifetime. afaict there is a common thread to date/time
representation in these two standards, as they both involve using a
"+/-" notation to represent time zones.
It is certainly annoying that there is a sign flip on the numeric
fields for the two standards (Posix and ISO8601). But only one, Posix,
has the preceding alpha time zone, so I should be able to figure it
out.
The annoying thing is that my token parsing is getting trickier, since
I also allow "January-1 2000" as a date specification, which from a
*token* standpoint is pretty similar to "gmt+8"...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California