TZ yet again

[Moderator, John Quarterman]

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 56