[tz] User time zones

[Guy Harris]

It sounds as if the only problem you're trying to solve is that of converting a date and time, plus a time-zone-and-DST abbreviation, into a UTC value, so that it can be, in turn, converted to local time in some other location.

The *best* way to solve that problem is, if possible, to have the text strings in question *not* use time-zone-and-DST abbreviations, but instead to use UTC or to use, as Russ Allbery said in his message, an explicit numerical offset-from-UTC value.  I.e., the best way to solve that problem is not to have it in the first place.

If, however, you're stuck with having to parse text that uses time-zone-and-DST abbreviations - i.e., you can't just avoid the problem - then, as long as the ambiguous cases can be eliminated (again, see past discussions of Australian time zone) or ignored, and as long as the abbreviations you specify in the database are used for all the strings you parse (i.e., no date/time/zone string uses an abbreviation *not* in the database), then your proposal to add special Olson database entries that have names that include the abbreviation and have a fixed offset-from-UTC would be one solution; another would be to maintain, as Russ suggested, a separate abbreviation-and-offset-from-UTC database.

Note that a mapping from abbreviations to offset-from-UTC is *NOT* necessary to make strptime() work, as strptime() is *not* required by the Single UNIX Specification to do anything useful with a time zone abbreviation in the string being parse - and, in fact, the Single UNIX Specification would have to be changed to require that a "struct tm" have a place to *put* the time-zone-and-DST abbreviation if it were to specify that something be done with %Z in strptime().

As for getdate(), well, they may say

	If %Z is being scanned, then getdate() shall initialize the broken-down time to be the current time in the scanned timezone. 

but what does that mean it should do with, for example, %Z matching "EST" if, when the program is run, the part of the Eastern time zone that has daylight savings time is in daylight savings time?  Is "the current time in the scanned timezone" the current time in the Eastern time zone in daylight savings time (that being what the clock on the wall says) or in standard time (because it's "EST")?

if the format string that matches it is, for example, "%Y-%m-%d %H:%M:%S %Z"?

(Note that I'm deliberately trying to avoid using the phrase "time zone".

The Olson database doesn't have entries for time zones; most of its entries are entries for regions on the Earth's surface.  A given region can have an offset-from-UTC that varies in fairly complicated fashions, and can even move from one time zone to another, e.g. the America/Indiana/Indianapolis region switched from the Central time zone to the Eastern time zone on April 24, 1955 - *and*, at the same time, it stopped having daylight savings time.  It then started having DST again in 1969, stopped having it in 1971, and started again in 2006.  That's why I'm saying "Olson database entries".

An abbreviation such as "EST" or "EDT" specifies both a time zone and a standard time vs. daylight savings time indication, so it doesn't correspond to just a time zone.  That's why I'm saying "time-zone-and-DST abbreviation".)