Thread: Need confirmation of "Posix time standard" on FreeBSD
Someone mentioned recently that a timezone style of "GMT+0800" was on
their FreeBSD machine as an allowed time zone, that its behavior was
the same as the usual ISO8601 timezone of "-0800", and that this
conformed to some sort of Posix standard.
I had posted patches for this, and have just modified the patch to be
cleaner and more robust.
Before committing this (or at least before completing our upcoming
beta period), I'd like confirmation that this actually matches
expected behavior for a machine implementing a "GMT+0800" (or similar)
time zone, and that it is indeed a Posix standard? Anyone??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart wrote: >Someone mentioned recently that a timezone style of "GMT+0800" was on >their FreeBSD machine as anallowed time zone, that its behavior was >the same as the usual ISO8601 timezone of "-0800", and that this >conformed tosome sort of Posix standard. > >I had posted patches for this, and have just modified the patch to be >cleaner and morerobust. > >Before committing this (or at least before completing our upcoming >beta period), I'd like confirmation thatthis actually matches >expected behavior for a machine implementing a "GMT+0800" (or similar) >time zone, and that itis indeed a Posix standard? Anyone?? > This seems to be the case for me. Debian GNU/Linux, using libc6 version 2.1.2: linda:olly $ date Sun Feb 6 23:55:52 GMT 2000 linda:olly $ TZ=GMT+8 linda:olly $ date Sun Feb 6 15:56:26 GMT 2000 linda:olly $ TZ=posix/Etc/GMT+8 linda:olly $ date Sun Feb 6 15:59:22 GMT+8 2000 -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Lift up your heads, O ye gates; and be ye lift up,ye everlasting doors; and the King of glory shall come in. Who is this King of glory? The LORD strong and mighty, the LORD mighty in battle." Psalms 24:7,8
Thomas Lockhart writes: > Someone mentioned recently that a timezone style of "GMT+0800" was on > their FreeBSD machine as an allowed time zone, that its behavior was > the same as the usual ISO8601 timezone of "-0800", and that this > conformed to some sort of Posix standard. > > I had posted patches for this, and have just modified the patch to be > cleaner and more robust. > > Before committing this (or at least before completing our upcoming > beta period), I'd like confirmation that this actually matches > expected behavior for a machine implementing a "GMT+0800" (or similar) > time zone, and that it is indeed a Posix standard? Anyone?? I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form :characters for implementation-defined behaviour or else std offset [dst [offset][,start[/time],end[/time]]] (spaces for readability only) where std is three or more bytes designating the standard time zone (any characters except a leading colon, digits, comma, minus, plus or NUL allowed) and offset is the value one must add to the local time to arrive at Coordinated Universal Time. offset is of the form hh[:mm[:ss]] with hh required and may be a single digit. Followed by gory details about the rest of the fields. Phew. --Malcolm -- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services
> I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions
> to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form
> :characters
> for implementation-defined behaviour or else
> std offset [dst [offset][,start[/time],end[/time]]]
> (spaces for readability only) where std is three or more bytes
> designating the standard time zone (any characters except a leading
> colon, digits, comma, minus, plus or NUL allowed) and offset is the
> value one must add to the local time to arrive at Coordinated
> Universal Time. offset is of the form hh[:mm[:ss]] with hh required
> and may be a single digit. Followed by gory details about the rest of
> the fields. Phew.
Thanks for the info. How do they define "the standard time zone"? Is
it *any* time zone, or "GMT", or some other set of choices?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart writes: > > I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions > > to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form > > :characters > > for implementation-defined behaviour or else > > std offset [dst [offset][,start[/time],end[/time]]] > > (spaces for readability only) where std is three or more bytes > > designating the standard time zone (any characters except a leading > > colon, digits, comma, minus, plus or NUL allowed) and offset is the > > value one must add to the local time to arrive at Coordinated > > Universal Time. offset is of the form hh[:mm[:ss]] with hh required > > and may be a single digit. Followed by gory details about the rest of > > the fields. Phew. > > Thanks for the info. How do they define "the standard time zone"? Is > it *any* time zone, or "GMT", or some other set of choices? It's "standard" in the sense of not-summer/not-daylight-savings rather than in the "POSIX compliance" sense. In other words, std can be any three bytes you like subject to the not-leading-colon, not-digits etc. constraints above. Later in the section it says that summer time is assumed to be one hour ahead of standard time if no offset follows dst. Also, If [an offset is] preceded by a "-"; the time zone shall be east of the Prime Meridian; otherwise it shallbe west (which may be indicated by an optional preceding "+"). That's the bit which shows that the "+" is OK. Aha, but I've just looked back at your original message and it refers to "GMT+0800" whereas POSIX requires a ":" between the hours and minutes. So in fact, "GMT+0800" is *not* legal and it should be "GMT+08:00" or "GMT+08" or "GMT+8" (single digit hours are allowed). --Malcolm -- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services
From: "Malcolm Beattie" <mbeattie@sable.ox.ac.uk> > Thomas Lockhart writes: > > Before committing this (or at least before completing our upcoming > > beta period), I'd like confirmation that this actually matches > > expected behavior for a machine implementing a "GMT+0800" (or similar) > > time zone, and that it is indeed a Posix standard? Anyone?? > > I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions > to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form > :characters > for implementation-defined behaviour or else > std offset [dst [offset][,start[/time],end[/time]]] It probably won't affect anything, but some implementations (FreeBSD most notably) have a bug in parsing TZ light savings string. The M notation gives one day off for switching to/from light savings. Actually, it incorrectly assumes Sunday as 0 for Zeller Congruence when it's Saturday. Gene Sokolov.
> > Thanks for the info. How do they define "the standard time zone"? Is
> > it *any* time zone, or "GMT", or some other set of choices?
> It's "standard" in the sense of not-summer/not-daylight-savings rather
> than in the "POSIX compliance" sense. In other words, std can be any
> three bytes you like subject to the not-leading-colon, not-digits etc.
> constraints above. Later in the section it says that summer time is
> assumed to be one hour ahead of standard time if no offset follows
> dst. Also,
> If [an offset is] preceded by a "-"; the time zone shall be east of
> the Prime Meridian; otherwise it shall be west (which may be
> indicated by an optional preceding "+").
> That's the bit which shows that the "+" is OK. Aha, but I've just
> looked back at your original message and it refers to "GMT+0800"
> whereas POSIX requires a ":" between the hours and minutes. So in
> fact, "GMT+0800" is *not* legal and it should be "GMT+08:00" or
> "GMT+08" or "GMT+8" (single digit hours are allowed).
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.
And we'll allow a superset of the Posix standard, so "GMT+0800" will
be legal (otherwise, it would disallow the ISO8601 standard which imho
should take precedence).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On 2000-02-08, Thomas Lockhart mentioned: > 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". > 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. > 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)? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> > 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