POSE proposal for TZ

Moderator, John Quarterman std-unix at ut-sally.UUCP
Fri Feb 21 00:14:02 AEST 1986


Date: Wed, 19 Feb 86 17:58:51 est
From: seismo!cbosgd.ATT.UUCP!mark (Mark Horton)

>  Yes, I was aware and worried about both problems.  However, in my
>search of timezones and DST rules worldwide I was not able to find any
>current or past rules that would have violated the assumptions.  Future
>rules are unlikely to break the current conventions for fear of confusing
>everybody (it's bad enough now).

You haven't looked hard enough.  Also, the minute you make an assumption,
some congressman or some MP in Britain or Japan or wherever will violate it.

>>>Discussion of (1) why Daylight Saving Time should not be constrained
>>>to either 0 or 2 changes per year;

There is a thing called "Double Daylight Time" which does exactly that.
I think it happened a few years back in some other country (Canada?)
Surely someone on this list can provide details.

>>>and (2) cautioning against a
>>>timezone name that may contain numerals, '+', or '-'.  Both points
>>>emphasized the possibility of future bizarre changes.

On the contrary, the notion of giving a time zone a name is an American
notion.  They also have names in Europe and Australia, but my impression
is that in many parts of the world, such as Japan, time zones are named
according to the ISO format +HHMM, e.g. Japan is +0900.

I'm afraid the variable TZ is already pretty badly broken - it can't be
used in Newfoundland or Central Australia or Saudi Arabia.  (We do have
sites on Usenet in Newfoundland - as far as I know, they all run 4BSD.)

elsie!ado has written some code with a much more flexible structure
(and some additional complexity, which I think is unavoidable.)  I
understand he's going to submit it to this group shortly.  I think
it merits serious consideration.  How much goes into the standard and
how much is left to the implementor isn't clear (e.g. is the format
of the time zone description file part of the standard?) but the code
is intended to be public domain, and it ought to make a good start.

	Mark

Volume-Number: Volume 5, Number 54



More information about the Mod.std.unix mailing list