std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/21/86)
Date: Thu, 20 Feb 86 13:11:50 est
From: Davidsen <seismo!rochester!steinmetz!davidsen>
I posted some thoughts on TZ previously, but I don't believe they got out,
due to a mail problem at that time. Forgive me if you've heard this before.
Some of the problems with TZ are:
1) non-standard names and abbreviations
2) strange DST rules
3) (1) and (2) change or may be added to.
Posible Solution #1:
-------------------
One method of solving these problems would be to use the value of TZ as
the name of a file in a special directory. These files would be
executable, and given the current date and time in GMT would return the
number of minutes to be added to GMT for that timezone (obviously the
return value is signed).
Drawbacks:
The only obvious one I see is overhead. A directory search + execution
is not nearly as nice as just getting a number from the environment. I
don't have a good idea what it would add as a percentage to the execution
time of localtime(). Since the time may change at any given instant, the
system can not just execute each program once and save the result.
Advantages:
Any number of timezones may be used, and timezones may be added or
deleted easily. If performance is really an issue (I'm not convinced
either way), then the directory could be cached in some way.
The algorithm may be easily changed and any level of complexity can be
handled. Programmers can handle more complexity than politicians.
Posible Solution #2:
-------------------
Add another form of the TZ variable which contains all the information
needed to handle the current algorithm. One posible form of this would be:
TZ=M:D:DOW:h:m:Name/Offset [;TZ=M:D:DOW:H:M:Name/Offset ...]
Where: (times in GMT)
M - month of the change
D - date of the change, as a value or range (ie "14" or "14-20")
DOW - day of the week, a value, range, or "*".
h - hour of the change
m - minute of the change
Name - the correct abbreviation for "date", etc.
Offset - signed minutes to add to GMT
Advantages:
This would be faster than posible solution #1.
The string can contain any number of changes.
Portable (all change times in GMT), and users at sites on site specific
time can "roll their own".
Covers the case where two locations want to use the same abbreviation
for "their" timezone. Note that this keeps the computer from getting
confused, not the user.
Disadvantages:
May not be able to handle some future really complex algorithm,
particularly one based on something like phase of the moon. However, this
can be updated on a yearly basis.
Ugly, hard to read.
Summary
-------
These are proposals for comment. Since I have not presented them as
final solutions, technical comments are more useful than raving flames.
They are not intended to address the problem of what time is used for
crontab, at, and uucp calls, but I see no reason to think that either
solution would exacerbate these problems, in fact solution #1 might be set
to always return local time (and ignore TZ) if the caller was root, bin,
uucp, etc.
Volume-Number: Volume 5, Number 56std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/24/86)
Date: Sun, 23 Feb 86 23:54:47 PST From: seismo!s3sun!sdcsvax!sdcsvax.UCSD.EDU!allyn (Allyn Fratkin) In article <4239@ut-sally.UUCP>, davidsen@steinmetz.UUCP (Davidsen) writes: > One method of solving these problems would be to use the value of TZ as > the name of a file in a special directory. These files would be > executable, and given the current date and time in GMT would return the > number of minutes to be added to GMT for that timezone (obviously the > return value is signed). Problem here: on most unix systems the parent only gets the lower eight bits of the exit value. This would mean max/min values of 127/-128. Not very practical if the value is supposed to be in minutes. Fine if the return value is in hours, though, but then you're still leaving parts of the world out. Besides, we've pretty much decided that we should at least have precision in minutes. Of course, we could make the precision HALF-hours. This is kind of silly, but is there anywhere in the world whose time is not an integral number of half hours away from GMT? [ The canonical example is Saudi Arabia, which has other problems, too. -mod ] By the way, I definitely feel that we need both a per-system time zone and a per-process (or per-user) time zone. Machines are stationary, but users are mobile (and sometimes far away). (I imagine that timezone is not in the dictionary because its not a word). [ Is filesystem a word? -mod ] -- From the virtual mind of Allyn Fratkin allyn@sdcsvax.ucsd.edu or UCSD EMU/Pascal Project {ucbvax, decvax, ihnp4} U.C. San Diego !sdcsvax!allyn "Generally you don't see that kind of behavior in a major appliance." -- Allyn Fratkin allyn@sdcsvax.ucsd.edu UCSD EMU/Pascal Project or U.C. San Diego {ucbvax, decvax, ihnp4}!sdcsvax!allyn Volume-Number: Volume 5, Number 60