timezones compatible with POSIX? [forwarded with permisison]

Guy Harris guy at netapp.com
Sat May 7 00:12:32 UTC 1994


> I work at the Santa Cruz Operation, a company that makes
> UNIX.  I am designing and implementing the part of our
> installation that sets time zones.  A search for complete,
> thorough timezone information led me to your anonymous ftp
> site, and I would like to use the information that you make
> available, if possible.

The best way to do that would simply be to pick up Arthur's *code*, as
well, and put it into SCO UNIX (SunOS 4.x, System V Release 4, and many
other versions of UNIX have already done so); modulo bugs, it *fully*
supports the POSIX standard for the TZ environment variable, as well as
supporting the nicer "Olson" scheme (e.g., to get US Pacific time, set
"TZ" to ":US/Pacific", rather than to whatever convoluted string is
required for the POSIX scheme).

> However I am having some trouble reconciling the Rule
> format with the format we use, which is also the POSIX standard
> for timezone strings (as far as I can tell, looking at my
> POSIX doc).  The problem is in the area of shifting to and from
> Daylight Savings Time.  Our format is to use a Julian day,
> a month/week/day, or a week/day format.  It's different enough from
> your Rule format that timezones defined in your format (such as Sun >= 11)
> do not work in our format for more than a few years at best (is
> that the 2nd week of the month?  The 3rd week?  It shifts.)

Unfortunately, as you note, the "Mm.n.d" scheme specified in POSIX does
not appear to allow rules of the form "Sun>=11" to be expressed
(sometimes it's the Sunday of the 3rd of the weeks in the month that
have a Sunday, which would be "Mm.3.0", and sometimes it's the Sunday of
the 2nd of the weeks in the month that have a Sunday, which would be
"Mm.2.0" - the "n" im "Mm.n.d" doesn't mean "the nth week of the month",
it means "the nth of the weeks in the month that actually have a day d",
e.g. if d is 0, it's "the nth of the weeks in the month that have a
Sunday").

The "Mm.n.d" scheme can, however, specify things such as "third Sunday
in the month", which would be "Mm.3.0"; the Olson scheme can also
specify that, as "Sun>=15".

I believe the way to map from "Mm.n.d" to an Olson-style scheme is that

	Mm.n.d

meaning "nth d-day of month m", maps to

	IN		ON
	month_name(m)	day_name(d)>=(1 + n*7)

where "day_name(d)" is the name of day "d", e.g.  "day_name(0)" is
"Sun", "day_name(1)" is "Mon", etc..  If "1 + n*7" is greater than the
number of days in the month, the "ON" field would be
"last{day_name(d)}", e.g. 

Thus, for example:

	M1.1.0

maps to

	IN	ON
	Jan	Sun>=1

	M1.2.0

maps to

	IN	ON
	Jan	Sun>=8

and so on, up to

	M1.5.0

which would map to

	IN	ON
	Jan	Sun>=36

except that no month has 36 days, so it'd map to

	IN	ON
	Jan	lastSun

However, if the number after the ">=" isn't a multiple of 7 plus 1,
I don't think there's a way to map that back into an "Mm.n.d" value.

If there are any countries where the rules require an Olson-style
specification other than "XXX>=(1 + n*7)", that's a strong argument in
favor of just picking up the Olson code and using that (given that, as
noted, it supports POSIX-style TZ settings, as well as settings that
just cause a compiled file to be read in).

If there *aren't* any such countries, the time zone files should be
cleaned up.



More information about the tz mailing list