I am concerned about the change of Europe/Vaduz into a link to Europe/Zurich. There was a long discussion about how and when Swiss time was standardised, yet no-one (except myself) seemed concerned that Vaduz is not actually in Switzerland. No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland, and if it does, when that decision was made by the legislature. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Russ Allbery Sent: 18 September 2013 00:10 To: tz@iana.org Subject: Re: [tz] draft of change summary for next tz release David Patte ₯ <dpatte@relativedata.com> writes:

And some of us prefer having at least one zone for each ISO 3166-1 country. Several of us understood the old theory file to require this. 1970 is an arbitrary computer geek cutoff point, with not much meaning to general time zone history.

None of these proposed changes make the database any better or worse in this regard so far as I can tell. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html.

On Wed, 18 Sep 2013, Lester Caine wrote:

My LMT *and* LMTZ data stays in 'extended' and only the 'condensed' data is kept separate.

You often mention "LMTZ". What does that term mean? --apb (Alan Barrett)

On Wed, 18 Sep 2013, Lester Caine wrote:

...

You often mention "LMTZ". What does that term mean?

It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone'

What is an LMT based zone? Zones are geographical areas, whereas LMT is associated with points.

Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones?

Sorry, I am still too confused about your terminology to try answering that. --apb (Alan Barrett)

On 2013-09-18 10:17, Lester Caine wrote:

Alan Barrett wrote:

...

...

...

You often mention "LMTZ". What does that term mean?

It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone'

What is an LMT based zone? Zones are geographical areas, whereas LMT is associated with points.

...

Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones?

Sorry, I am still too confused about your terminology to try answering that.

Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is. and different locations have a different offset. Anything on the same longitude will be the same time.

When people started standardising they agreed on a Local Mean Time that applied across a bigger area. Now while towns may be on the same longitude their time offset would be different depending on the other locations in their group? I'm probably wrong but I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention? So prior to that all time was 'mean time' and it just depended on which longitude was being used to set it. 1915 started messing things up with the first varying time rules?

Up until 1915 all we need to know is how the 'offset' from LMT was set when groups of locations agreed on a standard ... which is my 'LMTZ' data.

I think you may be saying that standard time really just follows LMT at some other location or longitude, and LMT for a location is set from that location's longitude; LMTZ documents pre-DST zones using an offset from some other arbitrary location's arbitrary longitude e.g. the local university observatory.

On Wed, 18 Sep 2013, Lester Caine wrote:

Alan Barrett wrote:

...

...

...

You often mention "LMTZ". What does that term mean? Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is. and different locations have a different offset. Anything on the same longitude will be the same time.

OK so far, except for the difference between solar time (where clocks are synchronised to midday every day, and days are not all the same length because the elapsed time between one solar midday and the next varies from day to day throughout the year) and mean time (where clocks are synchronised to a notional "mean" midday, and days are all the same length).

When people started standardising they agreed on a Local Mean Time that applied across a bigger area.

I'd say that they agreed on a time that applied across a bigger area. That time no longer deserved the name "Local Mean Time" because, for most locations in the zone, it was no longer the mean time that applied to their location.

I'm probably wrong but I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention?

Yes, I think so.

So prior to that all time was 'mean time' and it just depended on which longitude was being used to set it. 1915 started messing things up with the first varying time rules?

Up until 1915 all we need to know is how the 'offset' from LMT was set when groups of locations agreed on a standard ... which is my 'LMTZ' data.

They didn't agree on an offset from LMT. They couldn't, because LMT is different for every line of longitude in the area covered by the zone. They agreed on a place whose local mean time would be used throughout the zone, or they agreed on an offset between their time and the time in some other place. Anyway, I think I am starting to get the picture. When you say "LMTZ" you mean something like "A standardised time that applies across a geographical zone of significant size." I think it's confusing for you to refer to this time using a phrase that includes the words "Local Mean Time". --apb (Alan Barrett)

Guy Harris wrote:

...

Anyway, I think I am starting to get the picture. When you say "LMTZ" you mean something like "A standardised time that applies across a geographical zone of significant size." I think it's confusing for you to refer to this time using a phrase that includes the words "Local Mean Time". Yes. Standard time*happens* to be local time for some locations, but it's*not* local time for most of the locations to which it applies, and the locations for which it happens to be local time are less interesting than the resulting time offset (if you really*want* the longitude for those locations, you can calculate it from the time offset).

Let's just call it "standard time" - or, if you want to distinguish between time that doesn't shift over time and time that does ("daylight savings time", "summer time", etc.), call it "standard time without daylight savings time" or "standard time without summer time" or "standard time without seasonal shifts" or....

I prefer Alan's simplification. 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'? And that all this needs is a date and an offset. At some point in the future we may also need a 'clock' but I suspect that will not be so well documented? Lets keep the term 'timezone' for the more complex rules involving all the annual changes which is the only time 'rules' are required? Does that simplify the number of timezones problem? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Guy Harris wrote:

...

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: Sorry - in my mind 'date' is a timestamp all the time - and 1830's is a date with a 10 year time span ... genealogical standard terminaology. By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;)

...

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: 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? I'm not sure I even understand the subtlety of that statement. All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one. I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset?

I'm just trying to lay down a framework that we can agree on so we can start to hang what information we do have onto the right structure. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Guy Harris wrote:

...

By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;) By "24 hour days" do you mean "24 hour clock", as in "one hour past noon is 13:00:00 (or 13h 00m 00s or...) rather than 1:00:00 PM", or do you mean something else? If you mean "24 hour clock", the tzdb does not keep track of representational issues such as "12 hour clock vs. 24 hour clock"; are you suggesting that it should perhaps do so?

Why do you have to be so aggravating Guy ... This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database? History is important and recording the history of time needs a home ... even the changes to calendars fit into this history.

...

All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one. I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset? I don't think there will be anything other than tzids, whether a given tzid refers to a region that doesn't have DST/summer time/whatever or to a region that does, so I see no point to saying the former refers to a "timegroup" and the latter refers to a "timezone". If we decide to have separate tzids for all sets of locations that adopted standard time at a given date/time, then the "historic" database may well have thousands of tzids, and there will be a way of winnowing the database down to merge tzids that didn't differ before whatever date is chosen as the reference point. I presume that if a bunch of tzids were merged into one as part of the winnowing process, one of those tzids would be kept and the others discarded in the winnowed version of the database.

Again this is just nit picking when I'm just trying to create a path forward. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

On 2013-09-19 13:23, Guy Harris wrote:

On Sep 19, 2013, at 2:45 AM, Lester Caine <lester@lsces.co.uk> wrote:

...

This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. "Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else? This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database? I very strongly believe that information about the history of the adoption of 24-hour clocks does not belong in the TZ database, as that's orthogonal to the adoption of standard time; it could be maintained in a completely separate database used by code that displays times with a 12-hour or 24-hour clock depending on, for each time displayed, the convention in effect at that time (rather than just using the current convention). That code could, for example, use localtime() (which might use the tzdb) to convert a time_t to year/month/day/hour/minute/second, and then choose whether to display the hour as is or to do if (hour > 12) display hour-12 with "PM" else display hour with "AM" based on that other database. History is important and recording the history of time needs a home I'm unconvinced that it needs a single home, or that, even if it does, the tzdb is the right home. ... even the changes to calendars fit into this history. I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases. Again this is just nit picking when I'm just trying to create a path forward. I'm unconvinced that the path forward requires distinguishing between locations with complex rules and those that don't.

Julian or other calendar dates used when/after standard time was adopted can be statically converted to Gregorian as neither the C date/time functions nor the tzdb handle any other calendar. Historical information preceding adoption of standard time might be better hosted with a time history project. I would imagine historians and astronomers have done some of this kind of work already.

On Sep 19, 2013, at 4:07 PM, Lester Caine <lester@lsces.co.uk> wrote:

Guy Harris wrote:

...

...

This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. "Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else? http://www.time-for-time.com/clocks.htm I was simply referring to the fact that how time was measured differs vastly ... and at some point it may be necessary to handle that, including your example.

It may be necessary for some software to handle that. I *REALLY* don't see most code that uses the tzdb, or that uses APIs that use the tzdb, needing to care about pre-standardized-time clocks except to indicate the date and time when standardized time was adopted, and don't think the tzdb needs to handle that. I think that belongs elsewhere. And, again, I also don't think my example needs to be handled by the tzdb. Does anybody else believe the tzdb should handle the history of 12-hour vs. 24-hour clocks or of pre-standardized-time timekeeping other than recording when standardized time was adopted? If not, I don't see any point in further discussion of those topics on the tz list.

...

...

... even the changes to calendars fit into this history. I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases.

This is purely a mater of how far back the time related material is taken.

I don't think the time related material in the tzdb should go back before the establishment of standard time, for some meaning of "establishment", whether it means "adoption of standard time nationwide as civil time" or something looser. And, at this point, as per Brian Inglis' comment, the tz code shouldn't worry about the Julian calendar, and should leave it up to other code to handle that, so that I think *all* other calendars should be handled by other databases. If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database). Does anybody else believe that the tzdb should handle non-Gregorian calendars? If not, I don't see any point in further discussion of that topic on the tz list.

At the end of the day we still have no statement on how historic data will be handled.

Do we have a statement as to which historic data, other than the date and time of the establishment of standard time, and changes to regions' standard time and "daylight savings"/"summer time"/whatever rules, should be handled by the tzdb *at all*? I think we need that first, so we don't spend any time and energy discussing how to handle items that we're not going to handle. I propose 1) *not* including information about non-Gregorian calendars; 2) *not* including information about whether time is presented with a 12-hour or 24-hour clock; 3) for time prior to the establishment of standardized time, including *only* information about the date and time of its establishment; and personally like Alan Barrett's statement: In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data. Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users. so that the tzdb can have historical data about standardized time *but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits.

Guy Harris said:

Does anybody else believe the tzdb should handle the history of 12-hour vs. 24-hour clocks or of pre-standardized-time timekeeping other than recording when standardized time was adopted? If not, I don't see any point in further discussion of those topics on the tz list.

On the contrary, I don't even see how it's possible. There's no UK legislation that I'm aware of on the topic. I know that British Rail, Southend-on-Sea Corporation Transport, and Midland Red Bus all changed from 12-hour to 24-hour clocks in their published timetables in different years. Since there were scores if not hundreds of other transport companies in England alone, that's a huge amount of data that will never be found. And if one shop puts "open 9 to 6" on its sign while the one next door puts "Hours: 0800 to 1730", do we need to keep a record of that? The idea of itself is ridiculous.

...

...

I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb,

What about the adoption of other calendars? Didn't Sri Lanka spend some time on some other calendar? No, I don't believe this belongs in tzdb. It's interesting information, but that is *NOT* where it belongs.

I don't think the time related material in the tzdb should go back before the establishment of standard time, for some meaning of "establishment", whether it means "adoption of standard time nationwide as civil time" or something looser.

Agreed. And it should be further limited to information about the mapping from local standard time to UT (in the loose sense).

If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).

Seconded.

In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data. Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users.

so that the tzdb can have historical data about standardized time *but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits.

I think this is a good objective. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 20 September 2013 11:28, Lester Caine <lester@lsces.co.uk> wrote:

Clive D.W. Feather wrote:

...

...

If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).

Seconded. From which the data for TZ should be extracted ... if that is the way forward. So we are all working with the same set of data.

I suspect your desire to have all global historical data here at tzdb puts you in the minority. It is easy for you, and those who want to join you, to create an alternate repository, suck in the tzdb data and enhance it. The most likely approach is that you'd use tzdb data after 1970 and your own data before. For example, the vast majority of the 9 million Java developers will not want or expect additional IDs or additional historic data. By contrast, they will want and expect reasonable historic data for those IDs that do exist currently (and for that data to be enhanced over time, not degraded). Working elsewhere will give you a lot more freedom and avoid long discussions here, particularly as history tends to be subjective. This list should really be about current/future changes to tzdb, and occasional historic fixes to the current IDs. Stephen

Lester Caine wrote:

I'd almost argue that NO historic data is better than a SINGLE subset arbitrarily selected? Currently there is no mechanism to tell you that the historic data may not actually apply at all?

These are both valid points. It's certainly easy to remove data before 1970 automatically, and some platforms do that now (QNX, for example), so the first option is already there and some platforms already take it. As for the second, we could add a comment to each zone specifying the earliest time stamp such that the zone is known to be valid for all locations in its region after that time. The default would be 1970, which means the tz database trivially conforms to this pattern now. I see two problems with this idea, though. First, it needs to be integrated with winnowing, and it's not yet clear how that would work. Second, and more important, except for Europe/London and perhaps a handful of other places, we wouldn't know what value to put into the comment, other than the default "1970". This seems a fairly serious objection.

On Fri, 20 Sep 2013, Lester Caine wrote:

Subject: Re: [tz] What is LMTZ?

Please change the Subject when you change the topic.

I think we have reached the point where it's clear that TZ is never going to support anything before 1970 with any reliability.

That's not at all clear to me, at least for values of "reliable" that approximate the best information that volunteers are able to find and contribute. I thought that we had been talking about ways to allow the tz project to add much more pre-1970 data without adversely affecting those who don't want the run time overhead of the additional data, and that winnowing support would be one of the first steps towards that future.

winnowing is a pointless exercise unless you are prepared to add new data later.

Well, yes. The reason we have been talking about winnowing is that it will allow new data to be added later

So the only SAFE way to distribute a sub-set of TZ data is not to link it to past history that it is not 100% related to. The only problem remaining is how to allow a correct historic record to be used with the restricted TZ data.

I can't parse that, but I suspect that it's a conclusion based on a premise that I don't accept. --apb (Alan Barrett)

On Sep 18, 2013, at 1:06 AM, Lester Caine <lester@lsces.co.uk> wrote:

I'm trying to help with the idea of the addition of 'thousands' of timezones, and in the end if there is evidence for thousands in the USA then they simply need documenting anyway!

Perhaps they do, but whether that document needs to take the form of thousands of extra tzids is another matter. If they do, we should definitely give packagers of the tzdb, such as OS vendors, the option of *not* providing those thousands of extra tzids.

I would still like to tidy up 'backward' as well to actually contain dates that a particular alias was used from 'officially'.

As far as I'm concerned, "backward" should contain only links provided for backwards-compatibility reasons when a tzid name change occurred, e.g. Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Regina Canada/East-Saskatchewan Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific and, I think: Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey which are, I think, backwards-compatibility links introduced with the naming convention change. The only historical information associated with them relates to the history of the tzdb *itself*, and that's not of any use to people using the tzdb. There are also backwards-compatibility links introduced due to city name changes, e.g. not using "foreigner's" names for the city, e.g. Link Africa/Asmara Africa/Asmera Link Asia/Kolkata Asia/Calcutta Link Asia/Chongqing Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. Some links in "backwards" should perhaps be moved to other files. (The politically-sensitive links might fall into that category.)

On Sep 18, 2013, at 2:11 AM, Lester Caine <lester@lsces.co.uk> wrote:

Guy Harris wrote:

...

The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. The date it was first used is important as well ... both of which are just pulled from the release history.

What is "it", and what does "used" mean here?

On Sep 18, 2013, at 9:45 AM, Lester Caine <lester@lsces.co.uk> wrote:

What I mean is that the old names where in official use for a period of time and those names are used in material created during that time, so the period that they were valid for is important information.

What do you mean by "valid"? Unless some packager of the tzdb drops the "backward" file, those names are still "valid" in the sense that, for example, I can do TZ=US/Eastern date or TZ=America/New_York date and get the same answer (and I just *did* that on my OS X Mountain Lion system - Apple didn't drop the "backward" file - so the old names are *still* valid on my Mac, at least).

Lester Caine wrote:

I'm trying to help with the idea of the addition of 'thousands' of timezones, and in the end if there is evidence for thousands in the USA

Not just in the US. There would be thousands in the rest of the world too.

It sounds as if small pockets of communities combined over a period of time

That's a problem, but it's not the only problem. Communities also changed their minds about the time. Sometimes this was due to a war (the conquering army would keep its capital's time), sometimes other political events. I wouldn't be surprised if (say) France would need even more zones than the US, due to the wars fought there. Shanks lists fewer zones for France than for Indiana, but I suspect that's merely because Shanks lived near Indiana and could better research for Indiana. I do like the idea of having an 'extended' file, for zones that are not likely to be of general interest. Right now, though, we're just trying to get the next release out.

On 18.09.13 16:58, Paul Eggert wrote:

Wallace, Malcolm wrote:

...

No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland

Actually I made the attempt, and came up empty. And it wasn't a casual attempt: I scoured the literature, both online and in paper, in both English and German, in the best research library in southern California. Of course I may have missed something, and the National Library of Liechtenstein would probably be a better library for this; but I did try.

Alois Treindl wrote:

...

Vaduz (Liechtenstein) is a different country, with a different timezone history: no DST in 1941 and 1942.

I'm sorry, but there is no real evidence to support this claim, and I doubt that it's true. Shanks doesn't count as evidence, as he just makes things up. The Swiss astrology books don't count either, as they just make things up too -- my recent research proved them to be inventions even for *Switzerland*, so why should we pay attention to them for a neighboring country?

OK, I can confirm in this case that your intuition was right, and mine was wrong. You can link Europe/Vaduz to Europe/Zurich I found this source: http://www.eliechtensteinensia.li/LIJ/1978/1938-1978/1941.pdf which confirms on page 6 that Liechtenstein followed Switzerland in 1941 and 1942 I attach a screen copy, and translate only the last two paragraphs: ..during second world war, in the years 1941 and 1942, Liechtenstein introduced daylight saving time, adapting to Switzerland. From 1943 on central European time was in force throughout the year. From a report of the duke's government to the high council, regarding the introduction of a time law, of 31 May 1977.