Proposed time zone package changes (Fiji, Bahia Brazil, West Bank(Hebron))
Here are proposed changes to the time zone package. I'm releasing these changes now as the change to Bahia, Brazil, is due to take effect next Sunday week (8 or 9 days away, or something), so getting at least that change distributed now is urgent. The executive summary asia Changed the end date for Summer Time for this year (2011) to match reality reported by Steffen Thorsen. northamerica Corrected typo in (ancient) LMT zone offset as detected by Zefram. southamerica Resume Summer Time in Bahia, Brazil (following the standard Brazil algorithm, which causes Summer time to start Oct 16 this year, which matches the report.) australasia Adjust the end date for Summer time in Fiji in 2012 (Feb) as reported by Steffen Thorsen. That Bolivia will not start Summer time this year seems fortuitous as apparently we had no idea that it had been intended. Armenia's plan to abolish Summer Time can wait until it has ceased being a plan and become reality. As with Arthur's last update, any changes needed for Russia are deferred, mostly because I haven't been able to fathom what those changes need to be... (I wasn't paying that much attention to all the messages about this, as I didn't expect any of that to directly affect me - if someone who knows what is happening could send a proposed diff, that would help). One proposal that Arthur, Paul, and I had kicked around a little (very little) off list that might affect things there, was to abandon attempts to invent new time zone abbreviations for places that don't have one already in use, and instead just insert LST as a place holder (Local Standard/Summer Time). Anywhere that cares what the abbreviation is can have their preferred abbreviation, as always, other places, where we had been inventing strings just because we thought it was a good idea, will get LST instead. There was no plan to go back and change all the currently established invented abbreviations though, or not unless there's a request to remove a particularly poor choice, if we have any of those. And yes, we know that LST already exists with another interpretation (which can remain), we don't care. None of this is in this update, so feel free to express opinions on the advisability of adopting this policy for future new zones. The tzdata diff follows. I plan on releasing this next Monday (October 10) if there are no detected problems (and will almost certainly release whatever part of this is correct then). Note that I life in a timezone far east of Arthur, his Monday updates got to me on my Tuesday, so my Monday update will get to many of you on your Sunday.... kre *** asia 2011/10/07 06:09:10 1.1 --- asia 2011/10/07 06:54:28 *************** *** 2269,2275 **** 2:00 Palestine EE%sT 2011 Apr 1 12:01 2:00 1:00 EEST 2011 Aug 1 2:00 - EET 2011 Aug 30 ! 2:00 1:00 EEST 2011 Oct 3 3:00 2:00 - EET # Paracel Is --- 2269,2275 ---- 2:00 Palestine EE%sT 2011 Apr 1 12:01 2:00 1:00 EEST 2011 Aug 1 2:00 - EET 2011 Aug 30 ! 2:00 1:00 EEST 2011 Sep 30 3:00 2:00 - EET # Paracel Is *** australasia 2011/10/07 06:09:10 1.1 --- australasia 2011/10/07 06:21:11 *************** *** 303,308 **** --- 303,310 ---- Rule Fiji 2010 only - Mar lastSun 3:00 0 - Rule Fiji 2010 only - Oct 24 2:00 1:00 S Rule Fiji 2011 only - Mar Sun>=1 3:00 0 - + Rule Fiji 2011 only - Oct 23 2:00 1:00 S + Rule Fiji 2012 only - Feb 26 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Fiji 11:53:40 - LMT 1915 Oct 26 # Suva 12:00 Fiji FJ%sT # Fiji Time *** northamerica 2011/10/07 06:09:10 1.1 --- northamerica 2011/10/07 06:13:35 *************** *** 483,489 **** -8:00 US P%sT 1983 Oct 30 2:00 -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT ! Zone America/Sitka -14:58:47 - LMT 1867 Oct 18 -9:01:13 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 --- 483,489 ---- -8:00 US P%sT 1983 Oct 30 2:00 -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT ! Zone America/Sitka 14:58:47 - LMT 1867 Oct 18 -9:01:13 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 *** southamerica 2011/10/07 06:09:10 1.1 --- southamerica 2011/10/07 06:36:20 *************** *** 1034,1040 **** # of America/Salvador. Zone America/Bahia -2:34:04 - LMT 1914 -3:00 Brazil BR%sT 2003 Sep 24 ! -3:00 - BRT # # Goias (GO), Distrito Federal (DF), Minas Gerais (MG), # Espirito Santo (ES), Rio de Janeiro (RJ), Sao Paulo (SP), Parana (PR), --- 1034,1041 ---- # of America/Salvador. Zone America/Bahia -2:34:04 - LMT 1914 -3:00 Brazil BR%sT 2003 Sep 24 ! -3:00 - BRT 2011 Oct 16 ! -3:00 Brazil BR%sT # # Goias (GO), Distrito Federal (DF), Minas Gerais (MG), # Espirito Santo (ES), Rio de Janeiro (RJ), Sao Paulo (SP), Parana (PR),
Robert Elz said:
One proposal that Arthur, Paul, and I had kicked around a little (very little) off list that might affect things there, was to abandon attempts to invent new time zone abbreviations for places that don't have one already in use, and instead just insert LST as a place holder (Local Standard/Summer Time).
I was just re-reading the Theory file, and this already addresses the point: | When a country has a single or principal time zone region, append `T' to | the country's ISO code, e.g. `CVT' for Cape Verde Time. For summer time | append `ST'; for double summer time append `DST'; etc. | When a country has multiple time zones, take the first three letters of | an English place name identifying each zone and then append `T', `ST', | etc. as before; e.g. `VLAST' for VLAdivostok Summer Time. So the Belarus case should be BYT. -- 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
Date: Fri, 7 Oct 2011 09:27:07 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <20111007082707.GD6963@davros.org> | I was just re-reading the Theory file, and this already addresses the point: Yes, we know, the question is whether that really makes a lot of sense, and if it ought to be continued (it has been just as much ignored as used so far - Thailand is "ICT" (Indo China Time), not THT, which is something that is meaningless to locals. kre
Robert, About the change in Bahia, Brazil There is news in the media, however there is still no decree about it. I just send a e-mail to Zulmira Brandão at http://pcdsh01.on.br/ the oficial agency about time in Brazil, and she confirmed that the old rule is still in force. One thing about the news, is that the state governator made a statement, but to change the summer time federal decree is needed. The change can still occur, but it is better to wait for a confirmation of something oficial not news about a statement. Sorry my poor english, Guilherme follows the e-mail exchanged in Portuguese ---------- Forwarded message ---------- From: <zab@on.br> Date: 2011/10/7 Subject: Re: Horário de Verão na Bahia To: Guilherme Bernardes Rodrigues <oguilherme@gmail.com> Prezado Guilherme De acordo com o Decreto 6558 de 08 de setembro de 2008 entrará em vigor a partir da zero hora do dia 16 de outubro, até a zero hora do dia 26 de fevereiro de 2012 o HV. Os estados que entraram no HV serão RS; SC; PR; SP; RJ; ES; MG; MT; MS e DF. Portanto a BA não terá HV. Devo esclarecer que o HV depende de Decreto Federal. Atenciosamente Zulmira Brandão Divisão Serviço da Hora Quoting Guilherme Bernardes Rodrigues <oguilherme@gmail.com>: Bom dia Zulmira,
Gostaria de confirmar, este ano a bahia terá horário de verão? Gostaria também de saber se isso não depende de um decreto federal? Se sim para as duas perguntas qual é o decreto a respeito disso.
Obrigado,
Guilherme Bernardes Rodrigues
Date: Fri, 7 Oct 2011 14:47:23 -0300 From: Guilherme Bernardes Rodrigues <oguilherme@gmail.com> Message-ID: <CAAeks0GjPeCa0-RRPTWvZFz03-5fLf8Vo52enH7ivfXLdhAHrg@mail.gmail.com> | About the change in Bahia, Brazil [...] | The change can still occur, but it is better to wait for a | confirmation of something oficial not news about a statement. Definitely, consider that part of the update on hold for now - which could also mean that the update could be deferred for a while, since this was the driving force for the urgency - but (assuming I did not mess up my understanding of the change) we currently have incorrect data published for Asia/Hebron - the change (both actual, and in the database) is past now, so no current timestamps are being affected, but we should have the correct data out as soon as possible, so I still propose to issue an update on Monday. With that in mind, I'd still appreciate people verifying the proposed changes as best you're able (I can test that the syntax in the tzdata file is correct, and generates the transitions as I intended - but I cannot verify (in most cases) that the change proposed actually matches reality for the region. Second, I'd also appreciate assistance with getting the correct acknowledgments for the sources of the changes, and their paths leading to incorporation in the tz data files - 24 hours ago I had no plan to be doing this, and so was not really paying that much attention to the various messages about actual, planned, and possible updates - yesterday (my yesterday) I just scanned my copy of the list messages and tried to dig out all of the current updates I could find, but I was never sure I actually traced the original, or most authoritative, messages, and so in the data file updates I included none of the commentary that Arthur generally added providing source information. No slites intended, just insufficient time to make sure I had the correct data - so please don't be shy about telling me that it was you who discovered the change, and/or telling me how you'd like to be noted in the database comments. Third, it has been requested that I start the process (that the draft RFC anticipates) of providing some authentication for the distributed .tar.gz file (eventually files once a code update is required) and as long as that turns out to be no harder than I have been informed, I'm going to try it... I'll be using my own PGP key (that you can verify from the normal PGP key servers), most likely using gpg & the RSA key to do the signing (but if anyone says that pgp2 or pgp5 is superior, or that I should use the DSA key, I'll listen). Note that (certainly this first time) this is an experiment only, and you should not reject the data file because you cannot verify the signature (if that happens, it is far more likely that I messed up somehow than that the data file has been compormised!) Lastly, with regard to this last part of Guilherme's message ... | Sorry my poor english, No, no apology accepted, firstly because it wasn't needed, there was nothing poor at all about your English, and second, because even if there had been, there is absolutely no need to apologise for it - can you imagine what a message would be like if I attempted to make it in Portuguese? We (all) appreciate the efforts that everyone makes to communicate with us, and do do that (mostly) in English, and we need all of that input. It is the data we need mostly, please, no-one defer or avoid sending messages to the list because you aren't sure of your English ability. If needed, send in your own language, someone else will probably be able to translate, and in any case, much of the content of substance will usually be possible to extract (especially if you write dates using numbers...) Or, attempt English, no-one will complain about, or even comment on, its quality - that's not why we are here. kre
On 7 Oct 2011, at 20:18, Robert Elz wrote:
Lastly, with regard to this last part of Guilherme's message ...
| Sorry my poor english,
No, no apology accepted, ...
I second that.
We (all) appreciate the efforts that everyone makes to communicate with us, and do do that (mostly) in English, and we need all of that input. It is the data we need mostly, please, no-one defer or avoid sending messages to the list because you aren't sure of your English ability. If needed, send in your own language, someone else will probably be able to translate, and in any case, much of the content of substance will usually be possible to extract (especially if you write dates using numbers...) Or, attempt English, no-one will complain about, or even comment on, its quality - that's not why we are here.
That's one of the things I like about this community. It's interested in the data. It doesn't ask people to fill in this web form, use that email template, or use a particular jargon or language. It's the data that counts. I'm sure Robert didn't intend that as his manifesto for the post of TZ Coordinator, but in my opinion it would be a good one. Long may it continue like this. -- Peter Ilieve peter@aldie.co.uk
In case anyone needs a translation of these messages, here is my effort:
From Zulmira:
Dear Guilherme, In accordance with Decree 6558 of Sept. 8, 2008, summer time [HV = horario de verão = DST] will take effect from 0:00 on Oct. 16, until 0:00 on Feb. 26, 2012. The states which will enter into summer time are RS, SC, PR, SP, RJ, ES, MG, MT, MS, and DF [Rio Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Mato Grosso, Mato Grosso do Sul, Distrito Federal]. Thus, BA [Bahia] will not have summer time. I should clarify that summer time depends on a Federal Decree. Courteously Zulmira Brandão Time Service Division Guilherme's original message: Good day, Zulmira, I would like to confirm whether Bahia will have summer time this year? I would also like to know whether this depends on a federal decree? If the answer to both questions is yes, what is the specific decree in this case? Thank you, Guilherme Bernardes Rodrigues 2011/10/7 Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Robert, About the change in Bahia, Brazil [...] follows the e-mail exchanged in Portuguese
---------- Forwarded message ---------- From: <zab@on.br> Date: 2011/10/7 Subject: Re: Horário de Verão na Bahia To: Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Prezado Guilherme De acordo com o Decreto 6558 de 08 de setembro de 2008 entrará em vigor a partir da zero hora do dia 16 de outubro, até a zero hora do dia 26 de fevereiro de 2012 o HV. Os estados que entraram no HV serão RS; SC; PR; SP; RJ; ES; MG; MT; MS e DF. Portanto a BA não terá HV. Devo esclarecer que o HV depende de Decreto Federal.
Atenciosamente Zulmira Brandão Divisão Serviço da Hora
Quoting Guilherme Bernardes Rodrigues <oguilherme@gmail.com>:
Bom dia Zulmira,
Gostaria de confirmar, este ano a bahia terá horário de verão? Gostaria também de saber se isso não depende de um decreto federal? Se sim para as duas perguntas qual é o decreto a respeito disso.
Obrigado,
Guilherme Bernardes Rodrigues
It's official, the President signed a decree that includes Bahia in summer time. I did not find the decree yet but I am convinced now that the news reports the position of the president. I found nothing oficial about the 32 municipalities in Mato Grosso, I'm still looking and update when I find the decree. link whith the news: http://g1.globo.com/bahia/noticia/2011/10/dilma-assina-decreto-que-inclui-ba... Gwillim, thanks for the translation below. Guilherme On Mon, Oct 10, 2011 at 12:35 AM, Gwillim Law <gwillim@gmail.com> wrote:
In case anyone needs a translation of these messages, here is my effort:
From Zulmira:
Dear Guilherme,
In accordance with Decree 6558 of Sept. 8, 2008, summer time [HV = horario de verão = DST] will take effect from 0:00 on Oct. 16, until 0:00 on Feb. 26, 2012. The states which will enter into summer time are RS, SC, PR, SP, RJ, ES, MG, MT, MS, and DF [Rio Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Mato Grosso, Mato Grosso do Sul, Distrito Federal].
Thus, BA [Bahia] will not have summer time. I should clarify that summer time depends on a Federal Decree.
Courteously Zulmira Brandão Time Service Division
Guilherme's original message:
Good day, Zulmira,
I would like to confirm whether Bahia will have summer time this year? I would also like to know whether this depends on a federal decree? If the answer to both questions is yes, what is the specific decree in this case?
Thank you,
Guilherme Bernardes Rodrigues
2011/10/7 Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Robert, About the change in Bahia, Brazil [...] follows the e-mail exchanged in Portuguese
---------- Forwarded message ---------- From: <zab@on.br> Date: 2011/10/7 Subject: Re: Horário de Verão na Bahia To: Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Prezado Guilherme De acordo com o Decreto 6558 de 08 de setembro de 2008 entrará em vigor a partir da zero hora do dia 16 de outubro, até a zero hora do dia 26 de fevereiro de 2012 o HV. Os estados que entraram no HV serão RS; SC; PR; SP; RJ; ES; MG; MT; MS e DF. Portanto a BA não terá HV. Devo esclarecer que o HV depende de Decreto Federal.
Atenciosamente Zulmira Brandão Divisão Serviço da Hora
Quoting Guilherme Bernardes Rodrigues <oguilherme@gmail.com>:
Bom dia Zulmira,
Gostaria de confirmar, este ano a bahia terá horário de verão? Gostaria também de saber se isso não depende de um decreto federal? Se sim para as duas perguntas qual é o decreto a respeito disso.
Obrigado,
Guilherme Bernardes Rodrigues
I found the decree. DECRETO No- 7.584, DE 13 DE OUTUBRO DE 2011 Link : http://www.in.gov.br/visualiza/index.jsp?data=13/10/2011&jornal=1000&pagina=... Confirmed Bahia, and for now the split of the mato grosso municipalies not confirmed. On Fri, Oct 14, 2011 at 9:39 AM, Guilherme Bernardes Rodrigues < oguilherme@gmail.com> wrote:
It's official, the President signed a decree that includes Bahia in summer time. I did not find the decree yet but I am convinced now that the news reports the position of the president. I found nothing oficial about the 32 municipalities in Mato Grosso, I'm still looking and update when I find the decree.
link whith the news: http://g1.globo.com/bahia/noticia/2011/10/dilma-assina-decreto-que-inclui-ba...
Gwillim, thanks for the translation below.
Guilherme
On Mon, Oct 10, 2011 at 12:35 AM, Gwillim Law <gwillim@gmail.com> wrote:
In case anyone needs a translation of these messages, here is my effort:
From Zulmira:
Dear Guilherme,
In accordance with Decree 6558 of Sept. 8, 2008, summer time [HV = horario de verão = DST] will take effect from 0:00 on Oct. 16, until 0:00 on Feb. 26, 2012. The states which will enter into summer time are RS, SC, PR, SP, RJ, ES, MG, MT, MS, and DF [Rio Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Mato Grosso, Mato Grosso do Sul, Distrito Federal].
Thus, BA [Bahia] will not have summer time. I should clarify that summer time depends on a Federal Decree.
Courteously Zulmira Brandão Time Service Division
Guilherme's original message:
Good day, Zulmira,
I would like to confirm whether Bahia will have summer time this year? I would also like to know whether this depends on a federal decree? If the answer to both questions is yes, what is the specific decree in this case?
Thank you,
Guilherme Bernardes Rodrigues
2011/10/7 Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Robert, About the change in Bahia, Brazil [...] follows the e-mail exchanged in Portuguese
---------- Forwarded message ---------- From: <zab@on.br> Date: 2011/10/7 Subject: Re: Horário de Verão na Bahia To: Guilherme Bernardes Rodrigues <oguilherme@gmail.com>
Prezado Guilherme De acordo com o Decreto 6558 de 08 de setembro de 2008 entrará em vigor a partir da zero hora do dia 16 de outubro, até a zero hora do dia 26 de fevereiro de 2012 o HV. Os estados que entraram no HV serão RS; SC; PR; SP; RJ; ES; MG; MT; MS e DF. Portanto a BA não terá HV. Devo esclarecer que o HV depende de Decreto Federal.
Atenciosamente Zulmira Brandão Divisão Serviço da Hora
Quoting Guilherme Bernardes Rodrigues <oguilherme@gmail.com>:
Bom dia Zulmira,
Gostaria de confirmar, este ano a bahia terá horário de verão? Gostaria também de saber se isso não depende de um decreto federal? Se sim para as duas perguntas qual é o decreto a respeito disso.
Obrigado,
Guilherme Bernardes Rodrigues
On 2011-10-07 4:27, Clive D.W. Feather wrote:
Robert Elz said:
One proposal that Arthur, Paul, and I had kicked around a little (very little) off list that might affect things there, was to abandon attempts to invent new time zone abbreviations for places that don't have one already in use, and instead just insert LST as a place holder (Local Standard/Summer Time). I'm concerned about this suggestion.
I feel that the abbreviation LST would add some unnecessary confusion since it could mean either Local Standard Time, or Local Summer Time - ie: it gives no hint about the clock-advanced status. It, in fact, reminds me of the confused Australian ST/ST situation. And for those, such as me, that also use LST to represent Local Sidereal Time (in astronomy applications) it would be an extra layer of potential confusion.
Date: Mon, 10 Oct 2011 23:00:48 -0400 From: David Patte <dpatte@relativedata.com> Message-ID: <4E93B160.5030706@relativedata.com> | I feel that the abbreviation LST would add some unnecessary confusion | since it could mean either | Local Standard Time, or Local Summer Time - ie: it gives no hint about | the clock-advanced status. Yes, that was deliberate - that is, part of the aim is to try and reinforce the understanding that these abbreviations offer no meaningful value whatever... (except perhaps in one of the very few jurisdictions where they are actually defined, and even there, only if the application has some other means to know that the particular jurisdiction is the one of concern.) kre
On 10/11/2011 12:45 AM, Robert Elz wrote:
Yes, that was deliberate - that is, part of the aim is to try and reinforce the understanding that these abbreviations offer no meaningful value whatever... (except perhaps in one of the very few jurisdictions where they are actually defined, and even there, only if the application has some other means to know that the particular jurisdiction is the one of concern.)
kre Why not have a "no abbreviation" mode where the 'abbreviation' is just "-04:00", which _is_ meaningful?
Forgive me if I'm wrong, but I believe most robust implementations of the TZ database already have some way of expressing an offset in this way. If people want to use a meaningful offset identifier, e.g., "-04:00" (with or without the colon) as a replacement for an abbreviation like "EDT" in their individual cases, there is, practically speaking, very little they need to do to accomplish that. -- Tim Parenti On Thu, Oct 13, 2011 at 21:15, Random832 <random832@fastmail.us> wrote:
On 10/11/2011 12:45 AM, Robert Elz wrote:
Yes, that was deliberate - that is, part of the aim is to try and reinforce the understanding that these abbreviations offer no meaningful value whatever... (except perhaps in one of the very few jurisdictions where they are actually defined, and even there, only if the application has some other means to know that the particular jurisdiction is the one of concern.)
kre
Why not have a "no abbreviation" mode where the 'abbreviation' is just "-04:00", which _is_ meaningful?
Date: Thu, 13 Oct 2011 22:18:48 -0400 From: Tim Parenti <tim@timtimeonline.com> Message-ID: <CAFpi07wtWH_Sjh06QZ=X=Yp7qoto6Z+0zRQEnXh5Se_R5SZdvA@mail.gmail.com> | Forgive me if I'm wrong, but I believe most robust implementations of the TZ | database already have some way of expressing an offset in this way. That isn't the issue. What is of interest for this topic, is what the tz database (and code) should put in the tzname[] array &/or tm_zone field of the struct tm. Confusing that with what anyone would ever use to select a timezone, or identify one, or anything else useful at all, just muddies the waters. Personally, I'd have no great problem with putting some numeric zone indicator in place of the abbreviation, but apparently that might confuse some code that parses the output from the date command (and perhaps a few other similar things) and which expect that the abbreviation will be all alphabetic. Opting for caution when changing things is what this project has always done, and I see no reason to alter that policy, so I would not break anyone's code by altering the policy that the zone abbreviation (tzname[] or tm_zone) is a short alphabetic string (even an upper case short alphabetic string.) So, using -04:00 just isn't an option, sorry. LST, or LT, or almost anything else like that is possible - there's no need for it not to be ambiguous, or to be useful, that's already a lost cause, just for it to be syntactically consistent with current expectations. kre
On 2011/10/14 12:29, Robert Elz wrote:
So, using -04:00 just isn't an option, sorry.
LST, or LT, or almost anything else like that is possible - there's no need for it not to be ambiguous, or to be useful, that's already a lost cause, just for it to be syntactically consistent with current expectations.
What about something like UNKNOWN or ZZZ or so, then? LST gives the impression that it makes sense when it doesn't. Regards, Martin.
Date: Fri, 14 Oct 2011 13:51:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp> Message-ID: <4E97BFBB.2050500@it.aoyama.ac.jp> | What about something like UNKNOWN or ZZZ or so, then? LST gives the | impression that it makes sense when it doesn't. Yes, those would be possible too, but do remember, that except for in the few special cases where you know (roughly) what zone applies (some other way) and you know that in that zone the abbreviations mean something (how "you" know all that is anyone's guess), these things never make sense. kre
Robert Elz <kre@munnari.OZ.AU> wrote on Fri, 14 Oct 2011 at 12:27:32 +0700 in <1500.1318570052@epsilon.noi.kre.to>:
Yes, those would be possible too, but do remember, that except for in the few special cases where you know (roughly) what zone applies (some other way) and you know that in that zone the abbreviations mean something (how "you" know all that is anyone's guess), these things never make sense.
It is, however, a bit misleading to suggest that the special cases are rare and not frequent -- since they apply to the US, they are in fact extremely common for many many users. How do we feel about "___". --jhawk@mit.edu John Hawkinson
Date: Fri, 14 Oct 2011 01:45:07 -0400 From: John Hawkinson <jhawk@mit.edu> Message-ID: <20111014054507.GA19029@multics.mit.edu> | It is, however, a bit misleading to suggest that the special cases are | rare and not frequent I didn't say not frequent, but compared with the number of zones, they are relatively rare. | -- since they apply to the US, Yes, of course - and Australia, and even perhaps (probably) EC Europe. | they are in fact extremely common for many many users. First, no-one is even suggesting removing the information where it is useful, so America/New_York will keep producing EST/EDT way off into the foreseeable future. And if you (somehow) know that a date string is from North America, you could use the EST/EDT to convey information. But that "somehow" still needs to be handled - and other in the cases where the users "just assume" (rightly or wrongly) something has to convey that information - and I'd submit that whatever does, can just as easily convey everything needed (not just "this is north america", but "this is the eastern north american time zone and summer time applies"). Note that (other than perhaps with MST) none of the "big 4" north american zone abbreviations are unique, seeing EST, CST or PST doesn't tell you it that a date string is from north america. You need extra info. | How do we feel about "___". I am not sure that is quite alphabetic enough. kre
On Oct 14, 2011 6:16 AM, ""Martin J. Dürst"" < duerst@it.aoyama.ac.jp> wrote:
What about something like UNKNOWN or ZZZ or so, then? LST gives the impression that it makes sense when it doesn't.
I never gave much thought to tz abbreviations until I moved to Ireland and encountered the very ambiguous IST. http://www.worldtimezone.com/wtz-names/wtz-ist.html Might as well use LOL for all the meaning any of them have. Kevin On Oct 14, 2011 6:16 AM, ""Martin J. Dürst"" < duerst@it.aoyama.ac.jp> wrote:
On 2011/10/14 12:29, Robert Elz wrote:
So, using -04:00 just isn't an option, sorry.
LST, or LT, or almost anything else like that is possible - there's no need for it not to be ambiguous, or to be useful, that's already a lost cause, just for it to be syntactically consistent with current expectations.
What about something like UNKNOWN or ZZZ or so, then? LST gives the impression that it makes sense when it doesn't.
Regards, Martin.
On Fri, 14 Oct 2011, Robert Elz wrote:
Opting for caution when changing things is what this project has always done, and I see no reason to alter that policy, so I would not break anyone's code by altering the policy that the zone abbreviation (tzname[] or tm_zone) is a short alphabetic string (even an upper case short alphabetic string.)
Just to confirm your "suspicion". It would indeed break PHP's date parsing routines as things like "EDT"/"EST" and "-04:00" provides different types internally. Derick
Robert Elz wrote:
some code that parses the output from the date command (and perhaps a few other similar things) and which expect that the abbreviation will be all alphabetic.
FWIW, the POSIX standard for $TZ allows ASCII letters (of either case), digits, "+", and "-" in the abbreviation, and requires the abbreviation to be at least three characters long. So "LT" is not a good idea, nor is "___", but "-04:00" and "UT-4h" are valid abbreviations that timezone-handling code ought to be prepared for. However, if you use digits or punctuation in the abbreviation then the $TZ format requires quoting the abbreviation in angle brackets. So it looks like the historical practice (in the System V world), from which the POSIX standard is derived, only portably allowed letters. It's sane for us to (mostly) stick to alphabetic-only abbreviations. I say "mostly" because we already have a handful of exceptions. Firstly, the Etc/GMT+n and Etc/GMT-n zones, for which the abbreviation matches the zone name. For example, Etc/GMT+5 has the very clear and descriptive abbreviation "GMT+5". Unfortunately the abbreviation is totally misleading, because Etc/GMT+5 is actually a fixed 5 hours *behind* GMT. I understand that this is historically related to the POSIX $TZ format's inversion of offsets, but that actually makes it an even worse mistake: "GMT+5" as a POSIX $TZ means a fixed offset of -5h *with abbreviation "GMT"*. (We can deride Hugo Chavez for advising his people to put their clock forward half an hour to go from UT-4 to UT-4:30, but it seems to be a rule that everyone involved with timezones gets the direction of offsets mixed up sometime.) The other class of exception is the "Factory" zone, which has spaces in its abbreviation. That's liable to break timezone-handling software that can otherwise handle a wide range of characters in abbreviations: splitting date(1) output on spaces, for example, is otherwise a very sane behaviour. As I noted about a year ago (with discussion not reaching any conclusion), it also means that the POSIX-TZ field of that tzfile doesn't actually conform to POSIX. I think it would be better to change those spaces to dashes, which would be totally POSIX-acceptable. -zefram
On Oct 14, 2011, at 3:29 AM, Zefram wrote:
Robert Elz wrote:
some code that parses the output from the date command (and perhaps a few other similar things) and which expect that the abbreviation will be all alphabetic.
FWIW, the POSIX standard for $TZ allows ASCII letters (of either case), digits, "+", and "-" in the abbreviation, and requires the abbreviation to be at least three characters long. So "LT" is not a good idea, nor is "___", but "-04:00" and "UT-4h" are valid abbreviations that timezone-handling code ought to be prepared for.
I'm not sure "-04:00" is allowed; ':' is not one of the characters allowed in the "std" or "dst" part of the TZ setting. ($TZ can *begin* with ':'; that was added as an escape hatch to allow those weird Olson timezone folks to specify ":America/Los_Angeles" etc.. However, neither "std" nor "dst" in a doesn't-begin-with-colon specification can contain a colon.) "UT-4h", however, is allowed, as is, at least as I read the SUS, an RFC 2822-style "-0400". (Then again, so is "L+O+L", unless I've missed something; I'm not sure why they didn't have a tighter specification - the Rationale says The quoted form of the timezone variable allows timezone names of the form UTC+1 (or any name that contains the character plus ( '+' ), the character minus ( '-' ), or digits), which may be appropriate for countries that do not have an official timezone name. It would be coded as <UTC+1>+1<UTC+2>, which would cause std to have a value of UTC+1 and dst a value of UTC+2, each with a length of 5 characters. This does not appear to conflict with any existing usage. The characters '<' and '>' were chosen for quoting because they are easier to parse visually than a quoting character that does not provide some sense of bracketing (and in a string like this, such bracketing is helpful). They were also chosen because they do not need special treatment when assigning to the TZ variable. Users are often confused by embedding quotes in a string. Because '<' and '>' are meaningful to the shell, the whole string would have to be quoted, but that is easily explained. (Parentheses would have presented the same problems.) Although the '>' symbol could have been permitted in the string by either escaping it or doubling it, it seemed of little value to require that. This could be provided as an extension if there was a need. Timezone names of this new form lead to a requirement that the value of {_POSIX_TZNAME_MAX} change from 3 to 6.)
Date: Fri, 14 Oct 2011 11:29:16 +0100 From: Zefram <zefram@fysh.org> Message-ID: <20111014102916.GM10036@lake.fysh.org> | FWIW, the POSIX standard for $TZ And is totally irrelevant, as that's an input to the tz conversion routines, and we're discussing an output. They could be the same thing, but don't have to be (that is, there's no requirement that the abbreviation output be useful as a TZ value). kre
Robert Elz wrote:
And is totally irrelevant,
It doesn't seem *totally* irrelevant. It's true that we're not strictly limited to abbreviations that will fit into a POSIX-TZ value. But there are two reasons why it's a good idea to stick to that range. Firstly, we have a field in the tzfile which is specified to be in POSIX-TZ format. If our abbreviations don't match the POSIX spec then we can't properly fill that field: we either don't use it (and thus don't get the benefit of that facility) or we fill it with a non-conforming value (which won't necessarily work). Secondly, and more relevant to what we were discussing, the POSIX standard effectively determines a range of abbreviations that code handling time in a POSIX environment can expect to see and must be prepared to handle. Sticking within that range ensures a high degree of compatibility, though not as high as sticking just to letters. I note that the Theory section on abbreviations describes the POSIX rules and expresses a preference for using only letters. It also mentions the issue of spaces breaking space splitting. -zefram
Given that we know that names aren't unique, why don't we just use "NONE" for these cases? -- 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
Date: Fri, 14 Oct 2011 14:12:11 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <20111014131211.GA91325@davros.org> | Given that we know that names aren't unique, why don't we just use "NONE" | for these cases? That one is certainly a possibility, as are ZZZ (though that's ugly) and UNKNOWN (though that I think would actually be a misrepresentation). The LST suggestion came from an analogy with LMT, which is used for all (I think) zones in their pre standardised time days (Local Mean Time). The extension to Local Standard Time just seems appropriate to me. kre
On Sat, 15 Oct 2011, Robert Elz wrote:
That one is certainly a possibility, as are ZZZ (though that's ugly) and UNKNOWN (though that I think would actually be a misrepresentation).
The LST suggestion came from an analogy with LMT, which is used for all (I think) zones in their pre standardised time days (Local Mean Time). The extension to Local Standard Time just seems appropriate to me.
LOC or LOCAL would be least confusing I think. Take a look at this: $ TZ=LOC-3 date Sat Oct 15 05:59:25 LOC 2011 $ TZ=LOCAL-3 date Sat Oct 15 05:59:49 LOCAL 2011 $ Clean and clear, isn't it? While everyone seems to love abbreviations, or TLA, I would like to skip it here to make the meaning of the string clear. No need to make anyone wonder why he is using Latvian Summer Time like it was 1918 or something :-) Jaakko -- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
Robert Elz <kre@munnari.oz.au> wrote:
That one is certainly a possibility, as are ZZZ (though that's ugly) and UNKNOWN (though that I think would actually be a misrepresentation).
I thought ZZZ could be confused with Z, which is why I wondered about using the military / naval abbreviations. AAA ... ZZZ perhaps? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Faeroes: Southwest becoming cyclonic 6 to gale 8, perhaps severe gale 9 later. Very rough or high. Rain. Good, occasionally poor.
On Fri 2011-10-14T13:12:05 +0100, Zefram hath writ:
I note that the Theory section on abbreviations describes the POSIX rules and expresses a preference for using only letters. It also mentions the issue of spaces breaking space splitting.
Folks should be aware that the CalConnect tc-timezone-l list contains details about the IETF CALSIFY efforts which are preparing a draft related to the IANA registration of zones and the API for serving the contents of tzdata. My impression is that nomenclature issues like these are about to hit a new level of discussion. -- 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
participants (17)
-
"Martin J. Dürst" -
Clive D.W. Feather -
David Patte -
Derick Rethans -
Guilherme Bernardes Rodrigues -
Guy Harris -
Gwillim Law -
Jaakko Hyvätti -
John Hawkinson -
Kevin Lyda -
Peter Ilieve -
Random832 -
Robert Elz -
Steve Allen -
Tim Parenti -
Tony Finch -
Zefram