POSE proposal for TZ

[Moderator, John Quarterman]

Date: Sat, 22 Feb 86 21:14:28 cst
From: ihnp4!uiucdcs!ccvaxa!aglew at SEISMO.CSS.GOV (Andy Glew)

I do not know if double daylight savings has ever been used, 
but I heard a man from Canada's NRC talking about it on CBC radio last year.
The NRC is hoping that the US will go to DST earlier and stay later,
and from that it is only a short step to double time.
This makes better sense the closer you get to the pole.
I do know that several industries in Britain in WWII went to effective
double daylight savings time, by having people report to work earlier
in deepest summer (which is what we should do anyway).

What's all the fuss about, anyway? All times should be recorded in GMT,
since it's the closest thing we have to a standard clock.
Timezone information should only be used for local printing of the time
- dates, ls, etc. For this, the environment variable would be useful.

[ Several people have described what the problems are at length.
Since it's been a while, naturally there are people just starting
to follow the discussion who missed its beginning.  Perhaps I should
repost one of the explanatory articles.  So, a small poll:  If you've
come in late and want to know what all the fuss is about, send me
a note.  If you've been following the discussion all along and remember
a particular specification of the problem which was most clear to you,
let me know.  If I get enough of the former I will repost an
explanatory article, possibly chosen according to the latter.  -mod ]

Timestamps MUST be recorded in GMT, for projects that exchange code across
timezones.

[ The UNIX kernel has always kept internal time in GMT, as have most
other operating systems (VMS seems to be an exception).  There are,
however, programs which write text timestamps in local time.  -mod ]

It is conceivable that knowing what time of his local day the author last
modified his code might be useful, but instead of carrying a timezone
indication, why not carry a true location around, like latitude/longitude,
and look that up in a database (although it might get hairy for spaceships
travelling near c :-).

[ Timezones change per latitude and longitude. -mod ]

Even hairier idea:  have we considered non-24 hour days? Someday, someone is
going to have computers on the moon; they may still be running UNIX (and
Fortran, and Cobol) at that time, and there's no guarantee that they'll
stick to a 24 hour day. There've been a lot of studies that show that men
in isolation go to a 28-30 hour cycle, and without the sun rising to keep
you in synch, there's no reason not to change the definition of "day".
GMT will probably still be kept, but local time takes on a whole new meaning.
Maybe just leave an escape in any timezone environment variable for
local time conversions that don't simply consist of adding an offset?

[ Doubtless it will happen, but probably not within the effective
life of the current P1003 proposed standard.  I suggest the new
INFO-FUTURES list for such discussions.  I will repost the announcement
from UNIX-WIZARDS for it as the next article.  -mod ]

Andy "Krazy" Glew. Gould CSD-Urbana. 
UUCP: ...!ihnp4!uiucdcs!ccvaxa!aglew
ARPA Internet: aglew at gswd-vms.ARPA

[ PS:  Other than interpolating comments, there are exactly two things
which I can't resist doing to submitted articles before posting them
and without asking their authors first:  fixing obviously incorrect
spelling; and fixing incorrect network addresses, like UUCP addresses
given as being for USENET or old-style ARPANET addresses which won't
work anywhere in the ARPA Internet where domain nameservers are in use.
-mod ]

Volume-Number: Volume 5, Number 58