A simple proposal to move forward from where we are with reliable new rules: 1) Each inhabited ISO-3166 region must have at least one fully defined zone (LMT, pre and post 1970) 2) Links must not cross ISO-3166 region bouindaries Some of the rules that would require reworking (not a complete list): Europe/Busingen America/Atikotan America/Aruba America/Anguilla America/Port_of_Spain Europe/Zagreb Europe/Vatican Note that America/Montreal does not require reworking as a result of the first two new rules, although since it looks to have detailed historical information it would be unwise to lose that. Therefore I would add a third rule: 3) Existing pre-1970 data shall be respected If accepted, then these rules would be encoded in the theory file. Stephen
I do not favor adding rules that would place further political constraints on the tz database's contents. We already have too many problems with political issues that are unrelated to the core problem of timekeeping, and we should strive to avoid these problems rather than make them worse.
On 29 August 2013 20:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
I do not favor adding rules that would place further political constraints on the tz database's contents. We already have too many problems with political issues that are unrelated to the core problem of timekeeping, and we should strive to avoid these problems rather than make them worse.
Almost every recent problem you've faced is because you are trying to ignore the politics. Instead, embrace the political boundaries via ISO-3166. They are at the heart of time-keeping - just look at how often "government" occurs in the tzdb comments! I appeal for others to comment on the proposal, as it really is pretty darn simple and effective. #1 ensures that every region considered to be important enough to have an ISO-3166 code is given a full historic time-zone rule. #2 ensures that no political faux pas occurs by linking across boundaries. Stephen
On 29 Aug 2013 20:34, "Stephen Colebourne" <scolebourne@joda.org> wrote:
[stuff]
No solution will avoid politics. And someone starting a number of threads on this topic clearly has their own political agenda. Personally I think this series of threads should end because nothing good ever comes from them. So for what it's worth, that's my opinion. Kevin
You can't database your way out of politics, but you can mandate your way out. 1) Time Zones are Political, like it or not. 2) Everybody is biased politically 3) Nobody on this list wants to debate politics, recognizing that the discussions on this list should be based only on facts about timekeeping, and database efficiency, not politics. Therefore, I will dare to repeat myself; that the only way you can fulfill your complete mandate, knowing the above 3 constraints, is to base all political decisions on those of an outside group - ie: the ISO, or the UN. Anything else keeps the politics within the group, which is rediculous and unwanted. I would have been a heck of a lot easier to always follow ISO/UN rules and use Tel Aviv as recommended (whether we personally believe it is sensible), than the alternate path we are now being forced down. How much work do you expect everyone to do? No matter how much you database experts play with the data, the politics will never leave this list until it is mandated away and deferred to a 3rd party. Leave the politics with the people that know about politics!
On Aug 29, 2013, at 4:05 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
You can't database your way out of politics, but you can mandate your way out.
1) Time Zones are Political, like it or not. 2) Everybody is biased politically 3) Nobody on this list wants to debate politics, recognizing that the discussions on this list should be based only on facts about timekeeping, and database efficiency, not politics.
Therefore, I will dare to repeat myself; that the only way you can fulfill your complete mandate, knowing the above 3 constraints, is to base all political decisions on those of an outside group - ie: the ISO, or the UN. Anything else keeps the politics within the group, which is rediculous and unwanted.
I would have been a heck of a lot easier to always follow ISO/UN rules and use Tel Aviv as recommended (whether we personally believe it is sensible), than the alternate path we are now being forced down. How much work do you expect everyone to do?
No matter how much you database experts play with the data, the politics will never leave this list until it is mandated away and deferred to a 3rd party. Leave the politics with the people that know about politics!
Unfortunately that doesn't cure the problem, though it might perhaps shrink it. What happens is that you instead end up in a political fight about whose politics to select. When the problem is agendas and axe grinding, proposing to delegate that to outsiders who have a well established track record of serious agendas and axe grinding isn't going to work well. The handoff is bound to be just as controversial as the original issues, and the ongoing record of the chosen outsiders will continue to fuel the debate. This is certainly true for the specific example you mentioned and at least one of the agencies you proposed. paul
On 2013-08-29 16:40, Paul Koning wrote:
This is certainly true for the specific example you mentioned and at least one of the agencies you proposed. paul
I chose that example since that is what I believe precipitated this current debate and the subsequent massive change. It would certainly have been easier to accept that the UN might be wrong, but go with it, then to keep the fight going here, and rearrange the whole database. Most of us are far too busy to have to deal with political debate here. But of course difference requires humility that perhaps we on the list may not know as much about politics as the people that make it their fulltime job.
I happen to like the new proposal, although I don't really have much influence in the matter. The new proposal (appears to) restore the recent status-quo, and gives us clear guidance on how to move forward. I also agree that politics cannot be removed from the process. Politics is a fact of life, and while we don't necessarily need to embrace or encourage it, we certainly need to recognize and deal with it. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Stephen Colebourne Sent: Thursday, August 29, 2013 12:31 PM To: Time Zone Mailing List Subject: Re: [tz] Proposal for new rules On 29 August 2013 20:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
I do not favor adding rules that would place further political constraints on the tz database's contents. We already have too many problems with political issues that are unrelated to the core problem of timekeeping, and we should strive to avoid these problems rather than make them worse.
Almost every recent problem you've faced is because you are trying to ignore the politics. Instead, embrace the political boundaries via ISO-3166. They are at the heart of time-keeping - just look at how often "government" occurs in the tzdb comments! I appeal for others to comment on the proposal, as it really is pretty darn simple and effective. #1 ensures that every region considered to be important enough to have an ISO-3166 code is given a full historic time-zone rule. #2 ensures that no political faux pas occurs by linking across boundaries. Stephen
On 08/29/2013 01:06 PM, Paul Goyette wrote:
The new proposal (appears to) restore the recent status-quo I'm afraid that's not the case: the proposal would impose new political rules that have never been followed in the tz database, rules that would require politically-inspired makework. For example, it would forbid the longstanding link from Europe/Rome to Europe/Vatican. There is no technical reason to forbid that link; the only reason to forbid it would be political. (This is not the only example; I'm picking on the Vatican because it's relatively uncontroversial.)
We should avoid adding politics to the guidelines. It's extra complexity that we don't need. complexity that will make matters worse in the future.
On 29 August 2013 21:56, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/29/2013 01:06 PM, Paul Goyette wrote:
The new proposal (appears to) restore the recent status-quo I'm afraid that's not the case: the proposal would impose new political rules that have never been followed in the tz database, rules that would require politically-inspired makework. For example, it would forbid the longstanding link from Europe/Rome to Europe/Vatican. There is no technical reason to forbid that link; the only reason to forbid it would be political. (This is not the only example; I'm picking on the Vatican because it's relatively uncontroversial.)
The Vatican and Rome may have exactly the same time-zone rules but they do not have exactly the same LMT. Now I'll accept that the discrepancy is likely to be irrelevant to pretty much everybody, but it is a necessary effect of the two rules. The real aim of rule #2 is to stop things which are politically charged like Belgrade vs Zagreb. It also handles things like Aruba/Anguilla/PuetoRico which may not be politically charged now but could be in the future. If it were to ease things for others, I would be happy with rule #2 being should rather than must, although I personally feel its a step backward. Similarly, I would be OK with a city (zone ID) linking to two different ISO3166 regions if time is and always has been the same in both parts of the disputed city - I just think that scenario won't actually ever occur. The two rules do, unquestionably, make zone IDs a function of regions. I think that is a good thing. Note that I said zone ID within region, not city within region. This distinction is where the separation from politics can occur for the few that complain. In addition, the number of controversial IDs is very, very small. They can and should be sidestepped via an "avoid controversial zone ID names" rule - ie. use Tel Aviv, not Jerusalem. Specifically, no one can complain that Tel Aviv is in Israel and that Israel has an ISO3166 code. Politics sorted. Stephen
On Aug 29, 2013, at 3:51 PM, Stephen Colebourne <scolebourne@joda.org> wrote:
The Vatican and Rome may have exactly the same time-zone rules but they do not have exactly the same LMT.
"Do not have" or "did not have"? Do any clocks in the Vatican or Rome (other than sundials and clocks set by quirky people) *currently* keep LMT rather than some form of standard time? The TZ database currently does not indicate what LMT currently is for Rome or the Vatican.
Now I'll accept that the discrepancy is likely to be irrelevant to pretty much everybody,
And irrelevant to the time zone database until somebody updates the "europe" file to reflect the difference in LMT prior to the adoption, in both Italy and the Vatican, of standard time. So it sounds as if what you're saying here is "do not have links between two separate IDs even if the underlying zic-compiled files would be identical, if the two IDs correspond to locations in regions with different ISO 3166 country codes", to avoid offending people who don't want their region tied together with another region via a link, even if the two regions currently have the same data in the TZ file.
On 30 August 2013 00:29, Guy Harris <guy@alum.mit.edu> wrote:
On Aug 29, 2013, at 3:51 PM, Stephen Colebourne <scolebourne@joda.org> wrote:
The Vatican and Rome may have exactly the same time-zone rules but they do not have exactly the same LMT.
"Do not have" or "did not have"? Do any clocks in the Vatican or Rome (other than sundials and clocks set by quirky people) *currently* keep LMT rather than some form of standard time? The TZ database currently does not indicate what LMT currently is for Rome or the Vatican. And irrelevant to the time zone database until somebody updates the "europe" file to reflect the difference in LMT prior to the adoption, in both Italy and the Vatican, of standard time.
Yep. The difference in LMT is something that isn't important for Rome vs Vatican as they are the same city. But Rome vs San Marino? Also Atikokan vs Panama. I care about LMT at the moment because it is exposed to users of the APIs I write. IIUC, zic only really handles post-1970, but we can handle dates into the far past (thousands of years BCE). Now, I fully understand the relative insanity of applying much in the way of zones back then, but applying UTC everywhere would be equally wrong, thus LMT is currently the best I have.
So it sounds as if what you're saying here is "do not have links between two separate IDs even if the underlying zic-compiled files would be identical, if the two IDs correspond to locations in regions with different ISO 3166 country codes", to avoid offending people who don't want their region tied together with another region via a link, even if the two regions currently have the same data in the TZ file.
Yes. The proposed rule #2 is about avoiding offence across ISO3166 boundaries, whether or not such offence is likely. I actually think there is a good case for removing LMT from the main tzdb, and moving it to a separate lookup file. Following this discussion I'm increasingly of the opinion that my current use of naked LMT is a mistake (because the LMT data has been deleted and made inaccurate in the past, so cannot be relied on). Thus I need to use something else for the far past, say the most commonly used standard time between 1970 and 2010. Stephen
On Aug 30, 2013, at 1:15 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
Yep. The difference in LMT is something that isn't important for Rome vs Vatican as they are the same city. But Rome vs San Marino? Also Atikokan vs Panama.
Rome vs. Florence? Rome vs. Naples? Rome vs. Milan? Rome vs. Turin? etc.
I actually think there is a good case for removing LMT from the main tzdb, and moving it to a separate lookup file. Following this discussion I'm increasingly of the opinion that my current use of naked LMT is a mistake (because the LMT data has been deleted and made inaccurate in the past, so cannot be relied on).
Even if it *hadn't* been deleted, you can't use the TZ database to get LMT for arbitrary locations, so it's *still* a mistake. Frankly, it's a mistake that it was ever in the TZ database in the first place, given that a "time zone" only has a valid LMT value if its easternmost and westernmost edges are between the same one-second-apart meridians, and even *then* that's true only if you limit the resolution of LMT to one second. One might be incorrectly led to believe that "Europe/Rome" is a name that refers to the city of Rome rather than to the time zone the most-populous city of which is Rome, but that's not so, and saying it has Rome's notion of LMT is bogus unless all of the locations in that time zone have LMT values that are the same (to a resolution of one second; with sufficiently fine resolution you can't even say *Rome* has *an* LMT value). (And even if that's the case, it probably falls apart in, for example, North American time zones.)
On 30 August 2013 09:59, Guy Harris <guy@alum.mit.edu> wrote:
On Aug 30, 2013, at 1:15 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
Yep. The difference in LMT is something that isn't important for Rome vs Vatican as they are the same city. But Rome vs San Marino? Also Atikokan vs Panama. Rome vs. Florence? Rome vs. Naples? Rome vs. Milan? Rome vs. Turin? etc.
Not time-zone IDs, but I acknowledge with the sentiment.
I actually think there is a good case for removing LMT from the main tzdb, and moving it to a separate lookup file. Following this discussion I'm increasingly of the opinion that my current use of naked LMT is a mistake (because the LMT data has been deleted and made inaccurate in the past, so cannot be relied on).
Even if it *hadn't* been deleted, you can't use the TZ database to get LMT for arbitrary locations, so it's *still* a mistake.
Frankly, it's a mistake that it was ever in the TZ database in the first place, given that a "time zone" only has a valid LMT value if its easternmost and westernmost edges are between the same one-second-apart meridians, and even *then* that's true only if you limit the resolution of LMT to one second.
One might be incorrectly led to believe that "Europe/Rome" is a name that refers to the city of Rome rather than to the time zone the most-populous city of which is Rome, but that's not so, and saying it has Rome's notion of LMT is bogus unless all of the locations in that time zone have LMT values that are the same (to a resolution of one second; with sufficiently fine resolution you can't even say *Rome* has *an* LMT value). (And even if that's the case, it probably falls apart in, for example, North American time zones.)
Yep, LMT is clearly dodgy, but its the best we have. The core problem is what does the tzdb say that the offset was for times before the earliest zone. In reality, we know that people didn't really use clocks and just used local sun time. LMT is one encoding of that. Another would be a rounded to the nearest hour/half-hour value, which would be more arbitrary yet also more clearly arbitrary. Note that saying the tzdb starts at 1970 doesn't solve the problem. In both cases, users like me still need to have an offset for a zoneID in the far past. Stephen
Stephen Colebourne said:
Yep, LMT is clearly dodgy, but its the best we have. The core problem is what does the tzdb say that the offset was for times before the earliest zone.
I would suggest that we need a flag saying "standard time starts here" with the implication that times before that point are LMT; UIs would then have to ask for the *actual* location, not just the biggest city, to determine what LMT is. (For example, Great Britain is one zone in the database, and has always been one zone since GMT was adopted. But before that each town used its own LMT and there were lawsuits hinging in the difference. You even see public clocks with two minutes hands - one GMT and one LMT.) -- 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 Aug 30, 2013, at 2:38 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
On 30 August 2013 09:59, Guy Harris <guy@alum.mit.edu> wrote:
On Aug 30, 2013, at 1:15 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
Yep. The difference in LMT is something that isn't important for Rome vs Vatican as they are the same city. But Rome vs San Marino? Also Atikokan vs Panama. Rome vs. Florence? Rome vs. Naples? Rome vs. Milan? Rome vs. Turin? etc.
Not time-zone IDs, but I acknowledge with the sentiment.
The sentiment is "if we're going to care about LMT, we're going to need a bigger boat^W^W^Wa lot more TZIDs, so do we ("we" as in "the time zone database") *really* want to care about LMT?" I personally think the answer is a very strong "no", and that people who have attempted to use the tzdb for pre-standardized-time times have made a very big mistake, and people proposing to use the tzdb for pre-standardized-time times are making a very big mistake.
Yep, LMT is clearly dodgy, but its the best we have. The core problem is what does the tzdb say that the offset was for times before the earliest zone.
I would vote for "return an error". What should it say, in systems with a time_t big enough to encompass times that far back, for times before the formation of the solar system?
In reality, we know that people didn't really use clocks and just used local sun time. LMT is one encoding of that.
Yes, but tzdb time zones don't necessarily have *an* LMT value for a particular "proleptic UTC" value; the LMT value may differ depending on where you are. If somebody wants a mechanism to convert to local time for arbitrary time values (well, "arbitrary" limited to "during the period of human history when time was kept in a form where it makes sense"), that mechanism will need to take a longitude and latitude value as an argument, attempt to look that value up to find a tzdb zone ID and check what the tzdb says and, if it says "that tzdb zone didn't exist back then, they were using local time", convert to local time algorithmically and, if there are locations where simply assuming local time is based on the angular distance from the prime meridian is wrong, search some *other* database, developed and maintained by those who care about pre-standard-time local time values, for the appropriate time offset.
Note that saying the tzdb starts at 1970 doesn't solve the problem. In both cases, users like me still need to have an offset for a zoneID in the far past.
If "the far past" refers to a time before the establishment of standard time, do you need an offset for a time zone of some sort, or do you need an offset for a *location*?
On Fri 2013-08-30T11:34:25 -0700, Guy Harris hath writ:
Yes, but tzdb time zones don't necessarily have *an* LMT value for a particular "proleptic UTC" value; the LMT value may differ depending on where you are.
News from 1945 about the US prior to the 1883 adoption of railroad time: http://news.google.com/newspapers?nid=1499&dat=19451005&id=Sh4aAAAAIBAJ&sjid... In Kansas City each of the leading jewelers furnished his own "standard time," and no two of these standards agreed. Sometimes the range was as much as 20 minutes. Each jeweler had his own customers who set their watches by his regulator and were willing to wager on the correctness of his time. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Guy Harris said:
And irrelevant to the time zone database until somebody updates the "europe" file to reflect the difference in LMT prior to the adoption, in both Italy and the Vatican, of standard time.
Just to confuse things, Rome wasn't part of Italy until October 1871 [1] when the Papal States were absorbed into the new country (Italy itself wasn't created until 1861) following a plebiscite. The Papacy didn't accept this result and claimed to remain a separate country. In 1929 the Lateran Treaty created a new Vatican City State controlled by the Holy See. [1] Rome was captured by Italian armies on 20 September 1870. -- 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 Aug 30, 2013, at 4:54 AM, "Clive D.W. Feather" <clive@davros.org> wrote:
Guy Harris said:
And irrelevant to the time zone database until somebody updates the "europe" file to reflect the difference in LMT prior to the adoption, in both Italy and the Vatican, of standard time.
Just to confuse things, Rome wasn't part of Italy until October 1871 [1] when the Papal States were absorbed into the new country (Italy itself wasn't created until 1861) following a plebiscite.
The Papacy didn't accept this result and claimed to remain a separate country. In 1929 the Lateran Treaty created a new Vatican City State controlled by the Holy See.
Yeah, the name "Lateran Treaty" floated to the top of my brain shortly after I sent that, but I was too busy with other things to go back and follow up.
I also find it interesting that a move is afoot to remove The Vatican, which (perhaps not coincidentally) has the same status in the UN as the 'State of Palestine'. I have not made suggestions that the database be changed to reflect the recognized name 'The State of Palestine', recognized by a significant majority of nations, but there is no doubt that if the Vatican is removed, it could be used as justification to prevent the use of the name of Palestine in the DB, if that suggestion is proposed. On 2013-08-29 18:51, Stephen Colebourne wrote:
On 29 August 2013 21:56, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/29/2013 01:06 PM, Paul Goyette wrote:
The new proposal (appears to) restore the recent status-quo I'm afraid that's not the case: the proposal would impose new political rules that have never been followed in the tz database, rules that would require politically-inspired makework. For example, it would forbid the longstanding link from Europe/Rome to Europe/Vatican. There is no technical reason to forbid that link; the only reason to forbid it would be political. (This is not the only example; I'm picking on the Vatican because it's relatively uncontroversial.) The Vatican and Rome may have exactly the same time-zone rules but they do not have exactly the same LMT. Now I'll accept that the discrepancy is likely to be irrelevant to pretty much everybody, but it is a necessary effect of the two rules.
The real aim of rule #2 is to stop things which are politically charged like Belgrade vs Zagreb. It also handles things like Aruba/Anguilla/PuetoRico which may not be politically charged now but could be in the future.
If it were to ease things for others, I would be happy with rule #2 being should rather than must, although I personally feel its a step backward. Similarly, I would be OK with a city (zone ID) linking to two different ISO3166 regions if time is and always has been the same in both parts of the disputed city - I just think that scenario won't actually ever occur.
The two rules do, unquestionably, make zone IDs a function of regions. I think that is a good thing. Note that I said zone ID within region, not city within region. This distinction is where the separation from politics can occur for the few that complain.
In addition, the number of controversial IDs is very, very small. They can and should be sidestepped via an "avoid controversial zone ID names" rule - ie. use Tel Aviv, not Jerusalem. Specifically, no one can complain that Tel Aviv is in Israel and that Israel has an ISO3166 code. Politics sorted.
Stephen
--
On Aug 29, 2013, at 6:25 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
I also find it interesting that a move is afoot to remove The Vatican,
Where do you see such a move? Currently, Europe/Vatican is a link to Europe/Rome; what Paul Eggert noted is that the proposed rules would require separate entries for them. I don't see him recommending removing the entry for the Vatican, or even hinting at such a removal.
David Patte ??? said:
The Vatican, which (perhaps not coincidentally) has the same status in the UN as the 'State of Palestine'.
But for very different reasons. The Palestine issue is mired in politics. The Holy See is not a UN member because the Lateran Treaty forbids it from being involved in international politics except when all sides ask it to intervene in a matter. -- 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
Stephen Colebourne wrote:
I appeal for others to comment on the proposal, as it really is pretty darn simple and effective. #1 ensures that every region considered to be important enough to have an ISO-3166 code is given a full historic time-zone rule.
We used to have that rule. I'm OK either way on this.
#2 ensures that no political faux pas occurs by linking across boundaries.
This actually sounds like a source of *more* political tension. The whole concept of inter-country links (which you're saying we should avoid) depends on us associating each city with exactly one ISO 3166 region that "contains" it. There will on occasion be political disagreements about which one that should be. (Even apart from the ISO 3166 regions that uncontroversially overlap.) But if we do allow linking a city to a region that it is not in, we can sidestep these arguments. We're not claiming that the city is in your country; we're just claiming that it's the biggest city that uses the same timezone rules as you. People will still argue about which country a multiply-linked city "really" belongs to, but the argument is irrelevant to us. I think we could do with explicitly adopting an inclusive policy for zone.tab entries. Say: we include a city-country link iff there is a significant population that self-identifies with that country and uses the clock behaviour of that city. This is a relatively objective criterion that doesn't opine on the matters that are subject to big political disagreements. This approach applies regardless of whether we're attempting to provide every country with a named zone that is exclusively its own (your rule #1). It also applies regardless of the inclusiveness of our approach to pre-1970 data. Of course, a more inclusive view would lead to using fewer cross links. In the above, I'm using the term "country" as a synonym for "ISO 3166 region", by which I mean a region to which ISO 3166 assigns a regular alpha-2 code. I think this is uncontroversial ground on this list, but worth explicating in this context: the biggest political question we're ducking is what constitutes a country. Delegating that decision to ISO 3166 is an excellent policy, and was expressed well by Jon Postel in RFC 1591 "Domain Name System Structure and Delegation" (1994-03): # The IANA is not in the business of deciding what is and what is # not a country. # # The selection of the ISO 3166 list as a basis for country code # top-level domain names was made with the knowledge that ISO has a # procedure for determining which entities should be and should not # be on that list. This policy worked very well for the DNS until the Internet became big enough to wag the dog. I think it'll work for us for a while longer. -zefram
Zefram wrote:
In the above, I'm using the term "country" as a synonym for "ISO 3166 region", by which I mean a region to which ISO 3166 assigns a regular alpha-2 code. I think this is uncontroversial ground on this list, but worth explicating in this context: the biggest political question we're ducking is what constitutes a country.
Looking at the genealogical data, country boundaries change over time, so we can not rely on the current map of the world if the job is to be done correctly. No doubt in the future some areas will move from one time zone to another due to 'political' changes. Being practical, clocks were not being used widely before the 1700s, but prior to that time was actually quite 'accurate' based on the sundial, so much so that clocks set to local time then demonstrated the error across countries. 'Midday' in historic records can be reliably determined for any where on the world on any date but I think for now simply aiming to reflect the creation of time zones back in 1884 should be a starting point? -- 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 Thu 2013-08-29T21:44:34 +0100, Lester Caine hath writ:
think for now simply aiming to reflect the creation of time zones back in 1884 should be a starting point?
The 1884 International Meridian Conference rejected the notion of creating time zones. They considered the existing schemes and other proposals and then limited themselves to choosing the Prime Meridian and the Universal Day measured from there. They explicitly left any other local or standard times to local jurisdictions. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen wrote:
On Thu 2013-08-29T21:44:34 +0100, Lester Caine hath writ:
think for now simply aiming to reflect the creation of time zones back in 1884 should be a starting point? The 1884 International Meridian Conference rejected the notion of creating time zones. They considered the existing schemes and other proposals and then limited themselves to choosing the Prime Meridian and the Universal Day measured from there. They explicitly left any other local or standard times to local jurisdictions.
But it's still the right date to start from ;) It nailed down UTC for the first time ... and I think that a day will actually be 24 hours? Once again as you say - politics determined the rest! -- 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 Thursday, August 29, 2013, Lester Caine wrote:
Zefram wrote:
In the above, I'm using the term "country" as a synonym for "ISO 3166 region", by which I mean a region to which ISO 3166 assigns a regular alpha-2 code. I think this is uncontroversial ground on this list, but worth explicating in this context: the biggest political question we're ducking is what constitutes a country.
Looking at the genealogical data, country boundaries change over time, so we can not rely on the current map of the world if the job is to be done correctly. No doubt in the future some areas will move from one time zone to another due to 'political' changes.
Setting aside the current controversy, this kind of situation is already handled quite well: if after 1970, a chunk of territory switches from a country with one history of time zone rules to a another country with a different history, that by necessity forks that chunk of territory into a new time zone. If territory is exchanged between countries with identical time zone histories, no new zone need be forked. -- Scott Atwood
On Thu, Aug 29, 2013, at 15:17, Paul Eggert wrote:
I do not favor adding rules that would place further political constraints on the tz database's contents. We already have too many problems with political issues that are unrelated to the core problem of timekeeping, and we should strive to avoid these problems rather than make them worse.
These "problems" are not in evidence. There was not, in fact, any technical reason _not_ to make the requested change in the incident you are thinking of.
participants (13)
-
Clive D.W. Feather -
David Patte ₯ -
Guy Harris -
Kevin Lyda -
Lester Caine -
Paul Eggert -
Paul Goyette -
Paul Koning -
random832＠fastmail.us -
Scott Atwood -
Stephen Colebourne -
Steve Allen -
Zefram