Comments and mapping of tz zones to the real world
was: [tz] proposed changes: past Altai/Tomsk time zone shifts On Sat, May 5, 2012 at 8:48 PM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sat, 5 May 2012 04:11:55 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbVsY5SEs=3NGyau7T_aLW+W0cV18tofP3d_aDfjTw1M0w@mail.gmail.com>
| Putting something into the wrong timezone is by definition having a | bug in the TIMEZONE database.
No, once again, it is not, or not in any way that is important. There was no claim of importance, the claim only was that there is a bug.
| > If the comments in the zone file are wrong, | > we should certainly fix them sometime, | Now you change your opinion?
No, not at all, we fix erroneous comments, but erroneous comments are not a bug, as they don't affect the results, Of course they do. If one selects timezone Asia/Baku based on a comment that this is the tz zone for Chicago then one would get false offsets and false transitions.
they're just a minor insignificant error. Not to me, and maybe not for the people trying to find the Chicago zone data.
Like any error, such things should get fixed, but like other irrelevant errors, fixing them isn't urgent. Not for me.
| Any prove that all the view at | http://stats.grok.se/en/201204/List_of_tz_database_time_zones | are from list members?
List members can do whatever they like, and some of the people on this list (and associated with this project) certainly do attempt to make maps of timezones in one way or another. That's all fine, but it is not this project. I didn't claim that.
Your claim was " ...comments .... have no real importance and are generally only ever even seen by the people on this list (no-one else is really very likely to read through all of that stuff -...)" You provide no proof that the views of the Wikipedia page in question came only from list members. In absence of this, I think your claim is false.
| >(no-one else is really very likely to | > read through all of that stuff - zic certainly doesn't care.) | I read the comments before I was a list member.
Sure, there are people who look at this stuff, but not very many compared with the number of people who use the real product of this project - which is the zone database. Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York without reading the comments? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 05/06/2012 02:03 AM, Tobias Conradi wrote:
Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York
without reading the comments?
Fortunately, nearly everyone in Indiana is aware of the bizarre timezone patchwork. The simple rule, "if you're in Eastern time with DST, use New_York, if you're in Eastern time without DST, use Indianapolis; if you're in Central time, use Chicago" is correct for 99% of them, because the breakaway counties are farmland with few inhabitants. Out in the hinterland, it becomes "if you are in one of the half-dozen counties that have their own zones (named like the counties), use that." If you were to pick a random location on a map in Indiana and ask what time is observed there, I'd be hard pressed to answer. But in that particular case, better mapping might not even help; a great many inhabitants and businesses set their clocks to the large cities of Chicago or Indianapolis rather than whatever time their county legislatures have decided to observe that year.
On Sun, May 6, 2012 at 8:49 AM, Kevin Kenny <kkenny2@nycap.rr.com> wrote:
On 05/06/2012 02:03 AM, Tobias Conradi wrote:
Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York
without reading the comments?
Fortunately, nearly everyone in Indiana is aware of the bizarre timezone patchwork. What do you mean by "bizarre timezone patchwork."? Do you mean the existence of eleven zones for Indiana?
Adding to the above eight, these three: America/Indiana/Knox America/Indiana/Tell_City America/Chicago I would assume many people wouldn't know that there are eleven tz zones for locations in Indiana.
The simple rule, "if you're in Eastern time with DST, use New_York, if you're in Eastern time without DST, use Indianapolis; if you're in Central time, use Chicago" is correct for 99% of them, because the breakaway counties are farmland with few inhabitants.
Using http://en.wikipedia.org/wiki/Time_in_Indiana#tz_database and adding up Wikipedia 2010 population data for counties having a tz zone that is not one of the three you singled out, namely Chicago, New_York, Indianapolis, gives: Pulaski 13,402 Pike 12,845 Daviess 31,648 Dubois 41,889 Knox 38,44 Martin 10,334 Crawford 10,713 Clark 110,232 Floyd 74,578 Harrison 39,364 Switzerland 10,613 Starke 23,363 Perry 19,338 SUM 436,759 Indiana population is given with 6,483,802 for 2010. That is the three zones you singled out contain 93.3% of the Indiana population at most, thus cannot be correct for 99%.
Out in the hinterland, it becomes "if you are in one of the half-dozen counties that have their own zones (named like the counties), use that." I see no single zone that is named like a county.
The above county list contains two half dozens and one county. I don't know what you mean by "the half-dozen counties that have their own zones".
If you were to pick a random location on a map in Indiana and ask what time is observed there, I'd be hard pressed to answer. But in that particular case, better mapping might not even help; I was asking for how to determine the tz zone without using the data in the comments, i.e. without any mapping for individual counties at all. Because on Sat, 5 May 2012 04:11:55 +0200 Robert Elz claims:
" erroneous comments are not a bug, as they don't affect the results"
a great many inhabitants and businesses set their clocks to the large cities of Chicago or Indianapolis rather than whatever time their county legislatures have decided to observe that year. Any example for this? It could be added to the tz database and improve the mapping.
If only a minority in a given county does not observe what the law mandates and is in the tz db comments, then having the comments improves the results on average, thus the assumption "better mapping [compared to no mapping] might not help" is wrong. If a majority in a given country does not observe what the law mandates, I would ask on the tz mailing list, whether the information for that area should be changed. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Date: Sun, 6 May 2012 08:03:22 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbUnWXeYuQzE-_6AoUsa+c4S7NX2SOWQ57q-t7B55Gom6A@mail.gmail.com> | Of course they do. If one selects timezone Asia/Baku based on a | comment that this is the tz zone for Chicago then one would get false | offsets and false transitions. No, they wouldn't, they'd get perfectly good translations for Asia/Baku which is what they asked for (if those translations were incorrect, that would be a bug). That they didn't get what they hoped for is their (or someone else's) problem, not ours, as deciding what timezone people should use is just outside the scope of this project. Somewhere there just have to be boundaries on what we do, and this is one of them that's always been there. | Can you tell a way of how a user determines the correct zone for a | random location in Indiana, No, no idea, not my problem. The general process is that they select whichever of those towns (or locations) has (and has had) clocks showing the same time as their local clock, and use that one - if they are local, they probably will simply know that. For outsiders who have some reason to need to know Indiana time translations they would need to be told which timezone applies (or depending upon the application, the actual offset that applies to a particular timestamp). If the user in question happened to be me, I can assure you, giving lists of county names wouldn't help in the slightest. Note I am not saying that the problem you're posing isn't a real problem, nor that it shouldn't have work done on it. It is just that it is not our problem. The world has zillions of problems that we don't pretend to be attempting to solve, some of those are even related to time, and/or timezones - our job is limited to just making sure that we have all the zones that are needed (so there is a correct answer for that user to select an appropriate zone for their random Indiana location). Beyond that, someone else can work on it (perhaps with overlap from members of this list.) kre
On Tue, May 8, 2012 at 12:16 AM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sun, 6 May 2012 08:03:22 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbUnWXeYuQzE-_6AoUsa+c4S7NX2SOWQ57q-t7B55Gom6A@mail.gmail.com>
| Of course they do. If one selects timezone Asia/Baku based on a | comment that this is the tz zone for Chicago then one would get false | offsets and false transitions.
No, they wouldn't, they'd get perfectly good translations Thranslation? What translations? for Asia/Baku which is what they asked for (if those translations were incorrect, that would be a bug). Which translations, what are you talking about?
That they didn't get what they hoped for is their (or someone else's) problem, not ours, as deciding what timezone people should use is just outside the scope of this project. If the tzdb comments say zone A/B is the zone for location C, then Robert Elz comes and says it is not "our" (who is we? Robert Elz and his friends?) problem, then I think Robert Elz is right. But the problem that the tzdb users have is caused by a false information.
You, can say no, but it is. And false information, that causes users to have false offsets, is a bug. Because the scope of the tz project is .... Oh I think I quoted it already. Maybe this time you look into the Theory file and read what the scope of the tzdb is.
Somewhere there just have to be boundaries on what we do, Who is we?
and this is one of them that's always been there. ???
| Can you tell a way of how a user determines the correct zone for a | random location in Indiana,
No, no idea, not my problem. Fine, I wasn't claiming it would be the problem of Robert Elz. But it was Robert Elz who claimed
" the comments in the zone file ... have no real importance"
Sure, there are people who look at this stuff, but not very many compared with the number of people who use the real product of this project - which is the zone database.
The general process is that they select whichever of those towns (or locations) has (and has had) clocks showing the same time as their local clock, Haha. Why then do they need the tzdb, if they know the time already? Why is the tzdb having the 1970 cutoff point? What you say is false if one checks Theory file.
and use that one - if they are local, they probably will simply know that. For outsiders who have some reason to need to know Indiana time translations they would need to be told which timezone applies (or depending upon the application, the actual offset that applies to a particular timestamp). For Robert Elz's tzdb users would need to be told, since Robert Elz in his database doesn't care about false information.
This does not apply to what the IANA hosted tzdb project does. Do you have a mailing list for your tzdb project? Also it seems the Elz tzdb is much less known than the IANA / Olson tzdb.
If the user in question happened to be me, I can assure you, giving lists of county names wouldn't help in the slightest. I don't care about that.
Note I am not saying that the problem you're posing isn't a real problem, nor that it shouldn't have work done on it. It is just that it is not our problem. Who is we?
The world has zillions of problems that we don't pretend to be attempting to solve, Who is we?
some of those are even related to time, and/or timezones - our job Who is we? is limited to just making sure that we have Who is we?
all the zones that are needed (so there is a correct answer for that user to select an appropriate zone for their random Indiana location). But the user can find a false answer if comments are false.
Beyond that, someone else can work on it (perhaps with overlap from members of this list.) On what?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Who is we?
This does not apply to what the IANA hosted tzdb project does. Do you have a mailing list for your tzdb project?
Also it seems the Elz tzdb is much less known than the IANA / Olson tzdb.
I believe, when Robert says "we", he probably means himself, Arthur Olson, and Paul Eggert, who together have recently been the official maintainers of the IANA/Olson tzdb. His "we" may even include some other people on this mailing list, who also understand the tzdb project well. It is clear that you do not understand this project as well as they do - otherwise you would not constantly be questioning their judgement, in a manner that often comes across as rude and offensive. Whilst you seem to think that the "Theory" file is the ultimate arbiter of the scope of the project, you are wrong. It is the human beings named as maintainers who take the ultimate decisions on whether any particular proposed change is in or out of scope for the tzdb project. These human beings, through their long association with the tzdb project, are able to understand and interpret nuances, and also to make corrections to the text of the Theory file (where the Theory file turns out to fail to express the intent of the maintainers adequately). If you can manage both to be more polite whilst asking questions, and clearer about the changes you propose, you will probably find you will achieve a more rapid and willing response. But if you persist with your current abrasive approach, I think the maintainers may eventually get tired of your style and cease to respond at all.
Maybe this time you look into the Theory file and read what the scope of the tzdb is.
"The time zone rule file naming conventions attempt to strike a balance among the following goals: * Uniquely identify every national region where clocks have all agreed since 1970. [...] * Indicate to humans as to where that region is. * [...] " I presume you mean to invoke the second bullet point here. But do notice in the introductory sentence: "strike a balance between" - this indicates that the goals may conflict with each other, and human judgement is required. Also notice the word "attempt" - it is OK for the maintainers to prefer one goal over another in some situations, and to use an opposite preference in other situations. Regards, Malcolm This email and any attachments are confidential and may also be privileged. If you are not the addressee, do not disclose, copy, circulate or in any other way use or rely on the information contained in this email or any attachments. If received in error, notify the sender immediately and delete this email and any attachments from your system. Emails cannot be guaranteed to be secure or error free as the message and any attachments could be intercepted, corrupted, lost, delayed, incomplete or amended. Standard Chartered PLC and its subsidiaries do not accept liability for damage caused by this email or any attachments and may monitor email traffic. Standard Chartered PLC is incorporated in England with limited liability under company number 966425 and has its registered office at 1 Aldermanbury Square, London, EC2V 7SB. Standard Chartered Bank ("SCB") is incorporated in England with limited liability by Royal Charter 1853, under reference ZC18. The Principal Office of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In the United Kingdom, SCB is authorised and regulated by the Financial Services Authority under FSA register number 114276. If you are receiving this email from SCB outside the UK, please click http://www.standardchartered.com/global/email_disclaimer.html to refer to the information on other jurisdictions.
On Tue, May 8, 2012 at 9:51 AM, Wallace, Malcolm <Malcolm.Wallace@sc.com> wrote:
Who is we?
This does not apply to what the IANA hosted tzdb project does. Do you have a mailing list for your tzdb project?
Also it seems the Elz tzdb is much less known than the IANA / Olson tzdb.
I believe, when Robert says "we",
Believe doesn't help.
he probably means himself, Arthur Olson, and Paul Eggert, who together have recently been the official maintainers of the IANA/Olson tzdb. I see no indication on the mailing list that Robert Elz is the spokesperson for Arthur David Olson.
His "we" may even include some other people on this mailing list, who also understand the tzdb project well. Or not. It may also include people that don't understand it.
It is clear that you do not understand this project as well as they do Can you bring evidence for this?
- otherwise you would not constantly be questioning their judgement, That is a false claim by you. Questioning the judgement of any group of people doesn't mean the one who is questioning doesn't understand the topic.
in a manner that often comes across as rude and offensive. That is your interpretation.
Whilst you seem to think that the "Theory" file is the ultimate arbiter of the scope of the project, you are wrong. If I seem to do something then I am wrong? Wouldn't it be that I /seem/ to be wrong?
It is the human beings named as maintainers who take the ultimate decisions on whether any particular proposed change is in or out of scope for the tzdb project. And in /taking/ decisions they can introduce bugs. Or staying away from fixing as in
a) Paul Eggert http://mm.icann.org/pipermail/tz/2011-September/008776.html ::Hong Kong ... is a country b) Theory file: ::when countries change their name ... ::Hong Kong from UK colony to China -> The country Hong Kong changed its name from "UK colony" to "China"? This is not supported by c) http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#HK ::HK Hong Kong 1974 This issue had been reported at 2011-09-12 by Tobias Conradi http://mm.icann.org/pipermail/tz/2011-September/008783.html
These human beings, through their long association with the tzdb project, are able to understand and interpret nuances, Nuances of what or where?
and also to make corrections to the text of the Theory file (where the Theory file turns out to fail to express the intent of the maintainers adequately). Corrections can also be made with and without long association. What is needed is understanding the text. But I agree that with certain people it may be difficult to find an agreement on the correct answer for
-> The country Hong Kong changed its name from "UK colony" to "China"?
If you can manage both to be more polite whilst asking questions, Be polite whilst asking a question? You mean I should smile in front of my computer screen?
and clearer about the changes you propose, I think I was clear enough, and people can ask for clarification.
you will probably find you will achieve a more rapid and willing response. I am very content with the rapidness of the responses to the zones I proposed to be created. If you and Robert Elz didn't respond this doesn't matter. First of all I care about the tzdb. And if you and Robert Elz don't understand something, you are free to ask for clarification. But I have not seen any such request between September 2011 and March 2012.
But if you persist with your current abrasive approach, What do you think is my "current abrasive approach"? Can you show to the list members some examples?
I think the maintainers may eventually get tired of your style and cease to respond at all. I care about correctness in the tzdb. I hope maintainers are happy to receive bug reports as they help to improve the tzdb.
Maybe this time you look into the Theory file and read what the scope of the tzdb is.
"The time zone rule file naming conventions attempt to strike a balance among the following goals:
* Uniquely identify every national region where clocks have all agreed since 1970. [...] * Indicate to humans as to where that region is. * [...] "
I presume you mean to invoke the second bullet point here. A presumption about a thing is not the thing itself.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 08.05.2012, at 19:28, Tobias Conradi wrote:
On Tue, May 8, 2012 at 9:51 AM, Wallace, Malcolm <Malcolm.Wallace@sc.com> wrote:
Who is we?
This does not apply to what the IANA hosted tzdb project does. Do you have a mailing list for your tzdb project?
Also it seems the Elz tzdb is much less known than the IANA / Olson tzdb.
I believe, when Robert says "we",
Believe doesn't help.
What kind of tone is this anyway?
he probably means himself, Arthur Olson, and Paul Eggert, who together have recently been the official maintainers of the IANA/Olson tzdb. I see no indication on the mailing list that Robert Elz is the spokesperson for Arthur David Olson.
He's one of the official maintainers. If you have a problem with that, you can fork the database into your own project as permitted by the license. Good luck with that though...
in a manner that often comes across as rude and offensive. That is your interpretation.
That is not his interpretation, that is very likely the interpretation by the vast majority of people on this list. Stop being aggressive. Stop being abrasive. Stop being condescending. Start saying "please", start saying "thank you", start being friendly. Stop interpreting the subtle and polite bits of feedback you have received regarding your behavior as personal attacks, and start treating them as hints on how to improve your communication style.
If you can manage both to be more polite whilst asking questions, Be polite whilst asking a question? You mean I should smile in front of my computer screen?
If you don't know what he means, please get help in form of coaching on matters of etiquette, manners and social norms.
But if you persist with your current abrasive approach, What do you think is my "current abrasive approach"? Can you show to the list members some examples?
Nobody needs examples, Tobias. Everyone except you knows what he is talking about. It's the same kind of behavior that got you banned from Wikipedia (both de and en). Most of your feedback here is certainly valuable, but the way you get it across is, at best, counter-productive. Let me know if you'd like any specific pointers to what he might be referring to by "abrasive" off-list. I'll be happy to point them out if that helps you in the matter. David
On Tue, May 8, 2012 at 8:16 PM, David Zülke <david.zuelke@bitextender.com> wrote:
On 08.05.2012, at 19:28, Tobias Conradi wrote:
On Tue, May 8, 2012 at 9:51 AM, Wallace, Malcolm <Malcolm.Wallace@sc.com> wrote:
Who is we?
This does not apply to what the IANA hosted tzdb project does. Do you have a mailing list for your tzdb project?
Also it seems the Elz tzdb is much less known than the IANA / Olson tzdb.
I believe, when Robert says "we",
...
he probably means himself, Arthur Olson, and Paul Eggert, who together have recently been the official maintainers of the IANA/Olson tzdb. I see no indication on the mailing list that Robert Elz is the spokesperson for Arthur David Olson.
He's one of the official maintainers. Who is "he" referring to? I think Arthur David Olson is one, but IIRC Robert Elz too has been involved with maintaining.
If you have a problem with that, I don't have a problem with someone being a maintainer. If Robert Elz is one, I just hope he is not going to delete the mapping comments for the time zones for Indiana, because he doesn't seem to understand what they can be used for:
Q: "Can you tell a way of how a user determines the correct zone for a random location in Indiana," A: "No, no idea, not my problem. The general process is that they select whichever of those towns (or locations) has (and has had) clocks showing the same time as their local clock,"
in a manner that often comes across as rude and offensive. That is your interpretation.
That is not his interpretation, that is very likely the interpretation by the vast majority of people on this list. An interpretation can be shared by different people. I didn't wrote that it would be exclusively his interpretation.
Stop being aggressive. Stop being abrasive. Stop being condescending. Again, lack of any evidence for that to have been happened.
Start saying "please", You mean like in my first posting this year, after the old mailing list archive had been moved: http://mm.icann.org/pipermail/tz/2012-April/017638.html Or in the second one: http://mm.icann.org/pipermail/tz/2012-April/017640.html
Can David Zülke provide a list of how many "please" he expects from every single mailing list contributor, including himself? Can he also provide a list of how that was fulfilled?
start saying "thank you", You mean like here http://mm.icann.org/pipermail/tz/2012-May/017680.html ?
Can David Zülke provide a list of how many "thank you" he expects from every single mailing list contributor, including himself? Can he also provide a list of how that was fulfilled?
start being friendly. I think this tz mailing list is for maintaining the tzdb. I don't see that it is meant for exchanges friendly greetings.
Stop interpreting the subtle and polite bits of feedback you have received regarding your behavior as personal attacks, and start treating them as hints on how to improve your communication style. Looks a little bit as you would speak about the people that call my mailings aggressive, abrasive etc. Maybe my mailings are a help for them to improve their communication style, e.g. replacing "we" with something more specific.
But if you persist with your current abrasive approach, What do you think is my "current abrasive approach"? Can you show to the list members some examples?
Nobody needs examples, Tobias. I didn't talk about a need. I asked whether you can.
Everyone except you knows what he is talking about. Well, I know a lot of people that don't even know about the tz mailing list. But I educated several during the last weeks.
It's the same kind of behavior that got you banned from Wikipedia (both de and en). I think this claim without evidence is out of scope of the tz mailing list.
Most of your feedback here is certainly valuable, but the way you get it across is, at best, counter-productive. Counter-productive for what? If I point out errors in the tzdb or related statements, then it is exactly what I want to do.
Let me know if you'd like any specific pointers to what he might be referring to by "abrasive" off-list. I'll be happy to point them out if that helps you in the matter. Thanks for this offer. I think if claims about my editing are made on list, these claims should be backed by evidence on-list, or the claims may be regarded on-list as unbacked by evidence.
Like sometimes newspapers are forced by law to put up corrections in same size and at the same place where the original claim has been made. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
...
Stop being aggressive. Stop being abrasive. Stop being condescending. Again, lack of any evidence for that to have been happened.
Stop being argumentative. Take a cooperative attitude and help, rather than pick nits at every little phrase that someone writes. ...
Looks a little bit as you would speak about the people that call my mailings aggressive, abrasive etc. Maybe my mailings are a help for them to improve their communication style, e.g. replacing "we" with something more specific.
Your communication style is what is driving others to ask for a separate tz-announce list. They (as evidenced by private Emails which I will NOT share) and I are sick and tired of your style. While they and I still want, yeah, _need_, the tzdb and updates to it, we don't want to put up with your communication style. ...
On Tue, May 8, 2012 at 10:36 PM, Paul Goyette <pgoyette@juniper.net> wrote:
...
Stop being aggressive. Stop being abrasive. Stop being condescending. Again, lack of any evidence for that to have been happened.
Stop being argumentative. http://www.wordreference.com/definition/argumentative
"using or characterized by systematic reasoning."?
Take a cooperative attitude and help, I did.
rather than pick nits at every little phrase that someone writes. I didn't
...
Looks a little bit as you would speak about the people that call my mailings aggressive, abrasive etc. Maybe my mailings are a help for them to improve their communication style, e.g. replacing "we" with something more specific.
Your communication style is what is driving others to ask for a separate tz-announce list. Not supported by the first line at http://mm.icann.org/pipermail/tz/2012-May/017741.html
They (as evidenced by private Emails which I will NOT share) and I are sick and tired of your style. Why do you care so much about style? I thought the mailing list is about fixing bugs in the tzdb?
While they and I still want, yeah, _need_, the tzdb and updates to it, we don't want to put up with your communication style. If you only need the tzdb and the updates, you can have look to solve this at the thread http://mm.icann.org/pipermail/tz/2012-May/017731.html
I already got off-list reply thanking me for my proposal to achieve what has been asked for. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On May 5, 2012, at 11:03 PM, Tobias Conradi wrote:
Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York
without reading the comments?
Well, on the machine on which I'm typing this, they do so by launching System Preferences, clicking on "Date & Time", and either: 1) checking the "Set time zone automatically using current location" check box and letting the computer do the work of figuring out where you are and what zone would be appropriate or 2) dragging the blue "current time zone" stripe to "Eastern Standard Time" if it's not already there, or clicking on the map near Indiana, and selecting the appropriate entry from the "Closest City" drop-down list. I don't know whether any other desktop environments, or Linux distributions etc. that use those desktop environments, offer something similar to either of those (I tried it with Ubuntu 10.10 and it just offered a drop-down list of zone names and a map with cities to click on). I.e., the *user*, in the sense of "the end user", shouldn't have to even know about the time zone names; there should be a layer of software doing a better job of letting the user select the zone (or selecting it for them). The Theory file says:
This naming convention is not intended for use by inexperienced users to select TZ values by themselves (though they can of course examine and reuse existing settings). Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example.
However, that then means that the authors of the software, and the maintainers of whatever databases it uses, would need to figure out the right zones for particular locations, and the comments might help there. The comments aren't "part of the database" in the sense that zic reads them and produces a file based on what they say. They could, however, perhaps be viewed as "part of the database" in the sense that they are documentation for the database, in which case an error in a comment would be a documentation bug for the database. Some might argue that the database should include additional information, in machine-readable form, to, for example, give a "closest city", or some other regular-user-friendly descriptive information, for each zone, for use by that software. Unless the tz database takes on the burden of localization, however, that information would have to be in some form that would allow lookup in a database of localized names for cities. Currently, the Unicode Common Locale Data Repository: http://cldr.unicode.org/ has localized exemplarCity names for tz database zones: http://www.unicode.org/reports/tr35/ I don't know whether the maintainers of the CLDR use the tz database comments to pick the exemplarCity values.
On Wed, May 9, 2012 at 12:45 AM, Guy Harris <guy@alum.mit.edu> wrote:
On May 5, 2012, at 11:03 PM, Tobias Conradi wrote:
Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York
without reading the comments?
Well, on the machine on which I'm typing this, they do so by launching System Preferences, clicking on "Date & Time", and either:
1) checking the "Set time zone automatically using current location" check box and letting the computer do the work of figuring out where you are and what zone would be appropriate
Clever computer if it can determine the county where one is located. In case one is temporarily located in another county than the one, one wishes to set the zone for, this method can fail.
2) dragging the blue "current time zone" stripe to "Eastern Standard Time" if it's not already there, or clicking on the map near Indiana, and selecting the appropriate entry from the "Closest City" drop-down list.
As of 2012 there are several tz zones that yield Eastern Standard Time. In tzdata2012c/zone.tab there are the following ten: America/New_York Eastern Time America/Detroit Eastern Time - Michigan - most locations America/Kentucky/Louisville Eastern Time - Kentucky - Louisville area America/Kentucky/Monticello Eastern Time - Kentucky - Wayne County America/Indiana/Indianapolis Eastern Time - Indiana - most locations America/Indiana/Vincennes Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties America/Indiana/Winamac Eastern Time - Indiana - Pulaski County America/Indiana/Marengo Eastern Time - Indiana - Crawford County America/Indiana/Petersburg Eastern Time - Indiana - Pike County America/Indiana/Vevay Eastern Time - Indiana - Switzerland County One may want the zone for location A, but the "Closest City" drop-down may not include location A. The closest city may be across the border in a county that is located in another tz zone. Then one does not get the tz zone for location A.
I.e., the *user*, in the sense of "the end user", shouldn't have to even know about the time zone names; there should be a layer of software doing a better job of letting the user select the zone (or selecting it for them). The Theory file says:
This naming convention is not intended for use by inexperienced users to select TZ values by themselves Depending on how "inexperienced users" is defined, even experienced users may not be able to determine the correct zone by only looking at the zone names. I think the Theory file is misleading, buggy here.
e.g. America/Indiana/Vincennes is the zone for counties Daviess, Dubois, Knox, Martin Vincennes is the seat for http://en.wikipedia.org/wiki/Knox_County,_Indiana Not bordering Knox is http://en.wikipedia.org/wiki/Dubois_County,_Indiana Instead Dubois has borders to Pike County with seat Petersburg which is the reference point for America/Indiana/Petersburg and Crawford County with largest town Marengo, the reference point for America/Indiana/Marengo. I think that without the explicit statement in zone.tab or with comments in the northamerica file, one could not determine from the tzdb that Dubois is located in America/Indiana/Vincennes.
Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example. tzcode2012b/tzselect.8.txt says: FILES TZDIR/zone.tab Table of country codes, latitude and longitude, TZ values, and descriptive comments.
That may mean the end user has to rely on the comments column of zone.tab.
However, that then means that the authors of the software, and the maintainers of whatever databases it uses, would need to figure out the right zones for particular locations, and the comments might help there.
tzcode2012b/tzselect.8.txt doesn't indicate any mapping apart from that provided by the tzdb, i.e. the authors of the software didn't figure out any mapping (=create own mapping). And the DB that tzselect uses is the tzdb.
The comments aren't "part of the database" in the sense that zic reads them and produces a file based on what they say. Then zic uses only part of the database. I would use one software to determine the extend of the database. E.g. there is another software, tzselect, which according to tzcode2012b/tzselect.8.txt seems to use the comments column from the zone.tab.
They could, however, perhaps be viewed as "part of the database" in the sense that they are documentation for the database, in which case an error in a comment would be a documentation bug for the database. Agreed. That would not only include the comment column in the zone.tab, but also the comments in the region(?) files, e.g. in the "europe" file.
For the US, the comment column in the zone.tab may be sufficient. But for Russia (map at http://efele.net/maps/tz/russia/ ) the zone.tab data is not sufficient for the zones: Europe/Moscow Moscow+00 - west Russia Europe/Volgograd Moscow+00 - Caspian Sea Europe/Samara Moscow+00 - Samara, Udmurtia The comments in the europe file give for Europe/Volgograd # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast', # Volgogradskaya oblast'. Without that information mapping may fail. This information is needed. And if these comments put a location in the wrong timezone, than the mapping fails to. It would be a bug. That's what Tobias Conradi claimed at http://mm.icann.org/pipermail/tz/2012-May/017691.html Q: So, what is the effect if we put it into the wrong timezone? A: The database would contain a bug according to tzcode2011i/Theory: And what at least one user contested. Theory file says ============= ----- Scope of the tz database ----- The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). ============== If one puts Saratov Oblast into Europe/Moscow in the comments, while Saratov Oblast after the cutoff point observed the transitions as given in Europe/Volgograd, there would be a violation of sentence two of the scope section "...regions whose clocks all agree..." If such placement of Saratov Oblast is not a bug, then the Theory file contains a bug in the scope section. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On May 8, 2012, at 7:17 PM, Tobias Conradi wrote:
On Wed, May 9, 2012 at 12:45 AM, Guy Harris <guy@alum.mit.edu> wrote:
On May 5, 2012, at 11:03 PM, Tobias Conradi wrote:
Clever computer if it can determine the county where one is located.
It can, and did, determine the *city* where I'm located: http://support.apple.com/kb/HT4239 "Location Services allow applications to use information from Wi-Fi networks to determine your approximate location. In order to use Location Services, you must have an AirPort connection that can scan for nearby networks, and also a connection to the Internet."
In case one is temporarily located in another county than the one, one wishes to set the zone for, this method can fail.
Yes, in which case you'd un-check the "Set time zone automatically using current location" check box and set it manually. On the other hand, if one is temporarily located in a county that *is* the one for you wish to, at this time, set the zone, then this method wins. (That was the case, for example, when I was in Pennsylvania in late March. That was the point at which I turned on "Set time zone automatically using current location".)
2) dragging the blue "current time zone" stripe to "Eastern Standard Time" if it's not already there, or clicking on the map near Indiana, and selecting the appropriate entry from the "Closest City" drop-down list.
As of 2012 there are several tz zones that yield Eastern Standard Time.
Sorry, I wasn't clear enough. The stripe in question is on the map (see the screenshot in the URL I list up there), so it corresponds to a geographical region, not to a "time zone" such as the US Eastern time zone.
In tzdata2012c/zone.tab there are the following ten:
America/New_York Eastern Time America/Detroit Eastern Time - Michigan - most locations America/Kentucky/Louisville Eastern Time - Kentucky - Louisville area America/Kentucky/Monticello Eastern Time - Kentucky - Wayne County America/Indiana/Indianapolis Eastern Time - Indiana - most locations America/Indiana/Vincennes Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties America/Indiana/Winamac Eastern Time - Indiana - Pulaski County America/Indiana/Marengo Eastern Time - Indiana - Crawford County America/Indiana/Petersburg Eastern Time - Indiana - Pike County America/Indiana/Vevay Eastern Time - Indiana - Switzerland County
One may want the zone for location A, but the "Closest City" drop-down may not include location A. The closest city may be across the border in a county that is located in another tz zone. Then one does not get the tz zone for location A.
If I set the "current time zone" stripe to the one that reports "Eastern Standard Time", the Snow Leopard version of the System Preferences Date & Time pane offers only Fort Wayne and Indianapolis as "Closest City". I don't know whether this is because its list of "Closest Cities" is based on an older version of the CLDR or not based on the CLDR at all (paging Deborah Goldsmith...); the 2.1 version of the CLDR: http://unicode.org/Public/cldr/21/core.zip has, in bcp47/timezone.xml: tz database names City America/Indiana/Marengo Marengo (Indiana), United States America/Indianapolis America/Fort_Wayne America/Indiana/Indianapolis US/East-Indiana Indianapolis, United States America/Indiana/Vevay Vevay (Indiana), United States America/Indiana/Knox America/Knox_IN US/Indiana-Starke Knox (Indiana), United States America/Indiana/Vincennes Vincennes (Indiana), United States America/Indiana/Tell_City Tell City (Indiana), United States America/Indiana/Winamac Winamac (Indiana), United States America/Indiana/Petersburg Petersburg (Indiana), United States for Indiana. Yes, the "closest city" might be in a different state. The underlying problem there is "what user-friendly way is there to specify a tz database zone name to the user, so that they don't have to know obscure information that requires them to read the source files for the tz database?" Closest city? County name? Something else?
I.e., the *user*, in the sense of "the end user", shouldn't have to even know about the time zone names; there should be a layer of software doing a better job of letting the user select the zone (or selecting it for them). The Theory file says:
This naming convention is not intended for use by inexperienced users to select TZ values by themselves
Depending on how "inexperienced users" is defined, even experienced users may not be able to determine the correct zone by only looking at the zone names. I think the Theory file is misleading, buggy here.
The Theory file only implicitly, at best, says that the naming convention *should be* sufficient for "experienced" users in all cases; it's just saying that the goal is not to make it sufficient for users with arbitrary little experience to use just the names to select a zone (i.e., that the names are not chosen primarily to suggest to inexperienced users what zone is appropriate, just as the conventions for the LANG environment variable are not designed to make it possible for somebody unaware of ISO 3166, ISO 639, and whatever scheme is used to label character encodings to determine the correct LANG setting.
Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example.
tzcode2012b/tzselect.8.txt says: FILES TZDIR/zone.tab Table of country codes, latitude and longitude, TZ values, and descriptive comments.
That may mean the end user has to rely on the comments column of zone.tab.
Well, yes, in the sense that what tzselect prints comes from that column: $ cd tzdata2012c/ $ sh ../tzcode2012b/tzselect.ksh Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) none - I want to specify the time zone using the Posix TZ format. #? Americas Please enter a number in range. #? 2 Please select a country. 1) Anguilla 28) Haiti 2) Antigua & Barbuda 29) Honduras 3) Argentina 30) Jamaica 4) Aruba 31) Martinique 5) Bahamas 32) Mexico 6) Barbados 33) Montserrat 7) Belize 34) Nicaragua 8) Bolivia 35) Panama 9) Bonaire Sint Eustatius & Saba 36) Paraguay 10) Brazil 37) Peru 11) Canada 38) Puerto Rico 12) Cayman Islands 39) Sint Maarten 13) Chile 40) St Barthelemy 14) Colombia 41) St Kitts & Nevis 15) Costa Rica 42) St Lucia 16) Cuba 43) St Martin (French part) 17) Curacao 44) St Pierre & Miquelon 18) Dominica 45) St Vincent 19) Dominican Republic 46) Suriname 20) Ecuador 47) Trinidad & Tobago 21) El Salvador 48) Turks & Caicos Is 22) French Guiana 49) United States 23) Greenland 50) Uruguay 24) Grenada 51) Venezuela 25) Guadeloupe 52) Virgin Islands (UK) 26) Guatemala 53) Virgin Islands (US) 27) Guyana #? 49 Please select one of the following time zone regions. 1) Eastern Time 2) Eastern Time - Michigan - most locations 3) Eastern Time - Kentucky - Louisville area 4) Eastern Time - Kentucky - Wayne County 5) Eastern Time - Indiana - most locations 6) Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties 7) Eastern Time - Indiana - Pulaski County 8) Eastern Time - Indiana - Crawford County 9) Eastern Time - Indiana - Pike County 10) Eastern Time - Indiana - Switzerland County 11) Central Time 12) Central Time - Indiana - Perry County 13) Central Time - Indiana - Starke County 14) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties 15) Central Time - North Dakota - Oliver County 16) Central Time - North Dakota - Morton County (except Mandan area) 17) Central Time - North Dakota - Mercer County 18) Mountain Time 19) Mountain Time - south Idaho & east Oregon 20) Mountain Time - Navajo 21) Mountain Standard Time - Arizona 22) Pacific Time 23) Alaska Time 24) Alaska Time - Alaska panhandle 25) Alaska Time - southeast Alaska panhandle 26) Alaska Time - Alaska panhandle neck 27) Alaska Time - west Alaska 28) Aleutian Islands 29) Metlakatla Time - Annette Island 30) Hawaii ... (the strings in the last list come from the "comments" field in zone.tab).
tzcode2012b/tzselect.8.txt doesn't indicate any mapping apart from that provided by the tzdb, i.e. the authors of the software didn't figure out any mapping (=create own mapping). And the DB that tzselect uses is the tzdb.
Well, if "the tzdb" includes "zone.tab", yes. If it only means the files produced by zic, no - as the man page indicates, it reads both iso3166.tab and zone.tab, in addition to the time zone data files.
The comments aren't "part of the database" in the sense that zic reads them and produces a file based on what they say.
Then zic uses only part of the database.
If by that you mean "it ignores the comments in the source files", yes - they are, after all, comments, in the "comments in a source file" sense (rather than in the sense in which "comments" is used in zone.tab), and they're ignored by the zone info compiler (zic), just as the C compiler would ignore the comment in x += 2; /* multiply x by 43 and take its cosine */
I would use one software to determine the extend of the database. E.g. there is another software, tzselect, which according to tzcode2012b/tzselect.8.txt seems to use the comments column from the zone.tab.
Yes, it does use that. Perhaps that column should be called "description" rather than "comments", so that it's not confused with "comments" in the sense of # Lines beginning with `#' are comments. in zone.tab. That description is, however, in English: CN +4348+08735 Asia/Urumqi most of Tibet & Xinjiang so it's probably not sufficient for a "general users" user interface.
They could, however, perhaps be viewed as "part of the database" in the sense that they are documentation for the database, in which case an error in a comment would be a documentation bug for the database.
Agreed. That would not only include the comment column in the zone.tab, but also the comments in the region(?) files, e.g. in the "europe" file.
Well, the latter comments are "comments" in the "comments in a source file" sense, and thus only read and understood by humans - software reads it but discards it. They'd be useful for humans constructing other databases, such as the CLDR, from the tz database source files, but not useful for software.
But for Russia (map at http://efele.net/maps/tz/russia/ ) the zone.tab data is not sufficient for the zones: Europe/Moscow Moscow+00 - west Russia Europe/Volgograd Moscow+00 - Caspian Sea Europe/Samara Moscow+00 - Samara, Udmurtia
The comments in the europe file give for Europe/Volgograd # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast', # Volgogradskaya oblast'.
Without that information mapping may fail. This information is needed.
So perhaps either 1) zone.tab needs to have something better than "Moscow+00 - {xxx}" in it or 2) zone.tab needs more fields or perhaps whatever *localized* databases are used by various OS's/desktop environments' time zone selection UIs needs to have more information.
Theory file says ============= ----- Scope of the tz database -----
The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). ==============
If one puts Saratov Oblast into Europe/Moscow in the comments, while Saratov Oblast after the cutoff point observed the transitions as given in Europe/Volgograd, there would be a violation of sentence two of the scope section "...regions whose clocks all agree..."
Yes, that would be a bug in the database documentation, i.e. in the comments. Now, the non-comment portions of the zic source files enumerate all the regions - every line that begins with "Zone" gives a region. That does give a list of regions, but the non-comment portions don't "partition the world" in the sense that they indicate which particular parts of the world belong to particular regions; in effect, that's left up to the comments and the zone.tab file. Given that the non-comment portions of the zic source files don't actually indicate what parts of the world belong to particular zones, the non-comment portions of the zic source files don't provide enough information to indicate whether any of the regions in question have all clocks within that region agreeing post-Epoch, as they don't provide enough information to indicate what clocks are or aren't in that region....
Guy Harris, thanks a lot for this analysis and the detailed descriptions of the selection processes. I forgot a /not/ in my message: "I would /not/ use one software to determine the extend of the database."
tzselect, which according to tzcode2012b/tzselect.8.txt seems to use the comments column from the zone.tab.
Yes, it does use that. Perhaps that column should be called "description" rather than "comments", so that it's not confused with "comments" in the sense of
# Lines beginning with `#' are comments.
in zone.tab. I strongly support your proposal to better distinguish between comments in the source code sense and the text in the comment field of zone.tab. Renaming the field to "Description" sounds good to me. It allows for geographic description as well as for current real world time zone information as "Moscow+00" or "Eastern Standard Time".
But for Russia (map at http://efele.net/maps/tz/russia/ ) the zone.tab data is not sufficient for the zones: Europe/Moscow Moscow+00 - west Russia Europe/Volgograd Moscow+00 - Caspian Sea Europe/Samara Moscow+00 - Samara, Udmurtia
The comments in the europe file give for Europe/Volgograd # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast', # Volgogradskaya oblast'.
Without that information mapping may fail. This information is needed.
So perhaps either
1) zone.tab needs to have something better than "Moscow+00 - {xxx}" in it
or
2) zone.tab needs more fields
or perhaps whatever *localized* databases are used by various OS's/desktop environments' time zone selection UIs needs to have more information.
The proposal at http://mm.icann.org/pipermail/tz/2012-May/017755.html would follow 1) and improve {xxx}. to have a mapping to the real world.
CN .... Asia/Urumqi most of Tibet & Xinjiang ... probably not sufficient for a "general users" user interface.
It might be good to change this to the more common "most locations", i.e. Asia/Urumqi Tibet & Xinjiang - most locations Same for America/Halifax Atlantic Time - Nova Scotia (most places),... -> America/Halifax Atlantic Time - Nova Scotia (most locations),... /and/ to specify this in the Theory file. Maybe if there is "XXX - most locations" it should be required to have at least one line "XXX - <some locations not included in most locations>" -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
participants (7)
-
David Zülke -
Guy Harris -
Kevin Kenny -
Paul Goyette -
Robert Elz -
Tobias Conradi -
Wallace, Malcolm