[tz] What is LMTZ?

[Guy Harris]

On Sep 18, 2013, at 2:48 PM, Lester Caine <lester at lsces.co.uk> wrote:

> Yes that is all I'm trying to get at. but the point is that it is simply an agreed time for a location which may change as a location uses one or other 'standard'?


A given set of locations may well change what offset from GMT/UTC it uses; those are recorded in the Zone lines for the tzdb zone corresponding to that set of locations.

> And that all this needs is a date and an offset.

A set of dates/times and offsets, to handle the changes.

> At some point in the future we may also need a 'clock' but I suspect that will not be so well documented?

If by "need a 'clock' but I suspect that will not be so well documented" you mean that the changes occur at a particular time on a particular date, whether the particular time is well documented or not, Zone lines already handle that; see, for example, the Zone lines for America/New_York:

Zone America/New_York   -4:56:02 -      LMT     1883 Nov 18 12:03:58
                        -5:00   US      E%sT    1920
                        -5:00   NYC     E%sT    1942
                        -5:00   US      E%sT    1946
                        -5:00   NYC     E%sT    1967
                        -5:00   US      E%sT

which specify that the America/New_York tzdb zone switched from local time to Eastern Standard time, following standard US "seasonal time shift" rules (which didn't have seasonal time shifts until 1918) on 1883-11-18 12:03:58.

> Lets keep the term 'timezone' for the more complex rules involving all the annual changes which is the only time 'rules' are required?

Unfortunately, at least in the US (and possibly other countries), the term "time zone" is used to refer to regions with a given base standard time; that form of time zone may include multiple subregions with *different* "seasonal time shift" rules.  For example, the Mountain Standard Time zone includes Colorado:

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER
Rule    Denver  1920    1921    -       Mar     lastSun 2:00    1:00    D
Rule    Denver  1920    only    -       Oct     lastSun 2:00    0       S
Rule    Denver  1921    only    -       May     22      2:00    0       S
Rule    Denver  1965    1966    -       Apr     lastSun 2:00    1:00    D
Rule    Denver  1965    1966    -       Oct     lastSun 2:00    0       S
# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone America/Denver     -6:59:56 -      LMT     1883 Nov 18 12:00:04
                        -7:00   US      M%sT    1920
                        -7:00   Denver  M%sT    1942
                        -7:00   US      M%sT    1946
                        -7:00   Denver  M%sT    1967
                        -7:00   US      M%sT

and Arizona:

Zone America/Phoenix    -7:28:18 -      LMT     1883 Nov 18 11:31:42
                        -7:00   US      M%sT    1944 Jan  1 00:01
                        -7:00   -       MST     1944 Apr  1 00:01
                        -7:00   US      M%sT    1944 Oct  1 00:01
                        -7:00   -       MST     1967
                        -7:00   US      M%sT    1968 Mar 21
                        -7:00   -       MST

but, as that shows, Colorado currently largely follows the US "daylight savings time" rules and Arizona doesn't.

So I prefer terms such as "tzdb zone" to refer to those things that have tzids.  I'm not wedded to *that* term, but there should be *some* term other than "time zone" for that.

The tzdb currently does not have a concept of "time zone" in the sense of a region with a specified base time offset; are you suggesting that it add one?

> Does that simplify the number of timezones problem?

I don't think so.  The "number of timezones" problem, if by that you mean the problem that recording the times that particular regions adopted standard time in the tzdb would, as claimed, require thousands of new tzids, would not be solved by terminology - you're going to require thousands of new tzids no matter what.