- tz - lists.iana.org

may be a small mistake in the localtime.c code
by Z V June 6, 2012

June 6, 2012

Hello, The next piece of code looks like a mistake: localtime.c (1477-1484) while (i > 0 && sp->lsis[i].ls_trans == *sp->lsis[i - 1].ls_trans + 1* && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { ++hit; --i; } As far as I understand here are processed 'Leap' rules with '++' correction. If so, sp->lsis[i].ls_trans must be equal to sp->lsis[i - 1].ls_trans. BR, Igor

3 2

Are these valid timezone definitions?
by david singleton June 6, 2012

June 6, 2012

I posted a question earlier about a problem with exporting TZ, which was caused by a typo in the timezone man page on my ubuntu 10.10 system. When the typo was fixed the daylight savings end worked correctly. I've been given a new test in which one case seem to show a problem of when daylight savings starts, and one case when daylight savings ends. When a timezone is defined as : export TZ="NZST-23:00:00NZDT-24:00:00,M10.1.0,M3.3.0" the time is set one hour ahead when daylight savings begins. When I define a timezone with export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" there is no change in time when daylight savings ends. Is this a known problem? Or a problem with how the timezones are defined? I'll attach the test case. thanks Dave

3 2

Re: [tz] FW: may be a small mistake in the localtime.c code
by Arthur David Olson June 6, 2012

June 6, 2012

For (so far unused in the real word) double leap seconds, the binary file has different values for successive ls_trans/ls_corr pairs. For example, if the current "leapseconds" is changed so that the upcoming leapsecond is a double, a la... Leap 2012 Jun 30 23:59:60 ++ S ...then there will be an an entry with an ls_trans value of 1341100824 and an ls_corr value of 25 followed by an entry with an ls_trans value of 1341100825 and an ls_corr value of 26. Bottom line: Bradley White's code should be okay. --ado ________________________________________ From: Z V [igt31415926(a)gmail.com] Sent: Thursday, May 24, 2012 6:02 AM To: tz(a)iana.org Subject: [tz] may be a small mistake in the localtime.c code Hello, The next piece of code looks like a mistake: localtime.c (1477-1484) while (i > 0 && sp->lsis[i].ls_trans == sp->lsis[i - 1].ls_trans + 1 && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { ++hit; --i; } As far as I understand here are processed 'Leap' rules with '++' correction. If so, sp->lsis[i].ls_trans must be equal to sp->lsis[i - 1].ls_trans. BR, Igor

1 0

zone identifiers
by Tobias Conradi June 6, 2012

June 6, 2012

was: tz abbreviations / zdump for programmers On Tue, Jun 5, 2012 at 4:34 PM, Petr Machata <pmachata(a)redhat.com> wrote: > FWIW, in Czech Republic in particular, CET is translated as "SEČ" > (středoevropský čas), CEST as "SELČ" (~ letní ~). So apparently, these > things get translated. So are zone identifiers: Europe/Prague, for > example, should be presented to a Czech user as "Evropa/Praha", or some > such (the slash may be understandable, but maybe it should be somehow > localized away as well). So you do need translations of these strings. > Even to English, as a matter of fact: "Africa/Addis_Ababa" should > probably be presented as "Africa/Addis Ababa". I think that the > situation with abbreviations is similar. Identifiers are /not/ in English, like ISO country codes, or ISO language codes are /not/ in English. Not even the components are defined to be in English: America/Bahia_Banderas - Bahia de Banderas Antarctica/DumontDUrville - Dumont d'Urville Station Indian/... - Indian Ocean -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

2 1

bug in export TZ where day light savings spans Dec 31st?
by david singleton June 6, 2012

June 6, 2012

When I use the example from the timezone man page to define, and export a local TZ variable: export TZ="NZST-12.00:00NZDT-13:00:00,M10.1.0,M3.3.0" And then set the date to December 31st at 23:59 I see the clock roll over to 00:00 normally. But when I define a timezone using a positive offset I see time get set backwards at December 31st. I believe time should not get set back on December 31st for any timezones whose day light savings span December 31st. export TZ="NZST+12.00:00NZDT+13:00:00,M10.1.0,M3.3.0" date 123123592011.55 Sat Dec 31 23:59:55 2011 when I wait 5 seconds and check the date again I see the date has been adjusted to Dec 31st at 12:00? root@dstest2:~# date Sat Dec 31 12:00:01 NZST 2011 What is happening with TZs defined with a positive offset? I can reproduce this on Linux systems using glibc 2.5.90 up through glibc 2.12.1. I was hoping you could help me understand what is going on? thank you Dave

5 6

Let's keep focused on the time zone code and data
by Paul Eggert June 6, 2012

June 6, 2012

I'd like to ask people to keep the email focused on the time zone code and data, and not engage in personal attacks, worry about which Wikipedia user did what, etc.

1 0

mailing list, tone, respect, bugs, suggestions
by Tobias Conradi June 6, 2012

June 6, 2012

was: Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate On Wed, Jun 6, 2012 at 4:01 AM, David Patte <dpatte(a)relativedata.com> wrote: > I think this is the biggest issue with Conradi. I believe he has made 'some' > valuable comments and contributions over the last month (some - but not > all), Who sent more new bug reports and reminders of previously reported bugs than me? >but his attitude has turned the majority of this list against him What is your source for that. Maybe at first you could release a number of how many subscribers are on the list? > whether he has any points that have any merit or not. That would tell more about others than about me. > Mr. Conradi, if you so dearly want to 'fix bugs' in the db, as much as we > all do, I don't know how much all others do. I see no fix by the current TZ Coordinator at all. > I would suggest you learn how to present your suggestions as just > that - suggestions - and with humility. Why humility? Does that change the facts? >Maybe its an issue you have with translation, > or perhaps something else, but your presentation has turned > most people off providing you any futrther support for your ideas. Regrettably, because I think I sometimes make errors and am happy to learn from feedback. > You would > have gotten a lot further by granting those that have been on this list as > contributors or maintainers some respect; So you mean I didn't grant them some respect? I think I have gotten quite far. I have exposed lots of bugs in the database and in the management. If the management is not happy to hear this, and other people don't see the bugs, or are afraid to raise their voice, then shall I stop raising mine? What's up with the bugs in Siberia? > and I assure you that if you had > done that that you might have gained more consideration for your > 'suggestions'. Siberia stays wrong, despite people knowing it, because the one who reported it didn't show respect? What strange game is that? What's the purpose > If you have a suggestion for the database, please state it as a suggestion, Several instance where I titled emails with Propose/Proposal can be found at http://mm.icann.org/pipermail/tz/2012-May/thread.html The word "suggest" in a title of an email by me can be seen at http://mm.icann.org/pipermail/tz/2011-September/ "Post-1970 errors in Russian zones, suggest zones Asia/Tomsk, Asia/Barnaul " That is Siberia! > and back up your suggestion with documentation Can you show any bug report or proposal by me that came without? > - and stop accusing others of > not doing their part. Where did I do that? I think the only person that has an official part in fixing zone data bugs in the database is the current TZ Coordinator, named Paul Eggert. > That would help us all. "us"? Does that "us" include the users that are confronted with the IANA time zone database bugs? Bouvet Island, Siberia, place vs location, gmt vs utc, tz(a)elsie.nci.nih.gov vs tz(a)iana.org (the latter resulting in bouncing email)...? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

Re: [tz] Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate
by Alan Mintz June 6, 2012

June 6, 2012

I apologize to the list. I'll try to keep this brief, and I will _not_ engage in a flame war. I have no desire to work with someone who, I've now learned, just cannot be worked with. Constructive comments from others are welcome. At 2012-06-05 17:31, Tobias Conradi wrote: >In Wikipedia several accounts that added Olson/IANA time zone >information have been blocked and marked as sock puppets of Tobias >Conradi. Since User:Tobias Conradi did not edit since years, because a >handful of people once decided to block him, the only evidence for >"sock puppeting" is given as "behavioral". > >Behavioral for the User:TimeOfChange is to edit time articles: >http://en.wikipedia.org/wiki/Special:Contributions/TimeOfChange >No single talk page edit or anything else. > >Lately User Royaume du Maroc got blocked, who created: >http://en.wikipedia.org/wiki/Time_in_Florida Are you denying that you are "Royaume du Maroc" (RdM)? I've known about you for less than a month and it's clear to me that you are he. Give us a break and seek help. Seemingly coincidentally, I did some work on WP at the same time as RdM because I realized there were issues after first reporting to this list about a minor one. He seems fixated on the order in which things happened. I certainly don't care. Take all the credit you want. I simply want to get things right, and you can no longer do that, given that your past actions have you banned indefinitely. >BUT NOW THE REAL PROBLEM. AlanM1 is deleting IANA time zone from >Wikipedia e.g. Shiprock, South_Pole, Longyearbyen, Ljubljana >http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&di… I've spent a bunch of time on this in the last couple of days. I worked with the 2010e release on which the WP data was supposed to be based, and found numerous inconsistencies. Today, I decided that, versus correcting those, I might as well just use the latest data available - 2012c. The list on that page (http://en.wikipedia.org/wiki/List_of_tz_database_time_zones) is now consistent with what comes out of the Perl DateTime::TimeZone package, based on the 2012c release, merged with the zone.tab file from the same release (to get the coordinates and comments, which are not part of the perl package). This is also consistent with the 7 continent files. I still have to explore the relatively small list of diffs (including those you mentioned) to see why they were there before and not now. I suspect they are links. Note that the whole thing is a work in progress. I hardly had time to go get a burger after finishing hours of work on this before your drivel hit the list. >and at the same time introducing >| [[ISO_3166-1:|ISO_3166-1:]] >| >| [[PST8PDT]] > >into a list that claims to be based on a zone.tab listing. PST8PDT is >not in the current zone.tab file. No, it doesn't claim to be based on the zone.tab file. It's based on the 7 continent files. >Also the minus signs are changed into hyphen minuses, so that UTC >offset articles which use the minus sign are now reached via >redirects. OMG, the sky is falling! The way I read WP:MOS, I've used the correct character. The fact that the individual UTC* articles (which you created) use a different character doesn't change that at all. I will, however, investigate. What does this nitpicky bit of WP style have to do with the TZ mailing list? Is it really the right tone to take? >Furthermore the order of the elements in that list is not more the >same as in zone.tab, and the first column that allowed sorting in that >order got removed by AlanM1. Why is that order important? They are in order of the TZ identifier, which is the primary key of the database, and the logical order one would expect a list in, instead of the arbitrary and seemingly purposeless and undocumented number that was there. >Maybe some readers here with an account on Wikipedia can revert the >introduced errors and explain to AlanM1 what the errors are. You have yet to report anything that would be considered an error, and certainly not in a tone that would make anyone want to continue working with you (or at all). >E.g. due to South_Pole removal in the data templates, at >http://en.wikipedia.org/wiki/Time_in_Antarctica >there is now "[[ISO 3166-1:IANA time zone id not in >Template:Tz/country code|IANA time zone id not in Template:Tz/country >code]]" As I said, work in progress. Fixing any broken links is next. >Also due to not using the data templates at >http://en.wikipedia.org/wiki/List_of_tz_database_time_zones >Wikipedia is now open to inconsistency between this list and data >display in other places. Before the change the list showed to a wide >extend the data contained in the templates, so people could easily >check for correctness. I did use those templates, and the data in the individual column templates are now all in sync. The problem is that I was unable to save the template-using version of the "List of tz database time zones" article, apparently because of the resulting complexity of all those template transclusions. If you had read the change log, or given me time to document it on the talk page, you would have seen my note about that: "(Update to 2012c, data added directly to article because of performance problems when templated. This may be a temporary problem - will try again later.)" You never saw this problem because you didn't use the templates for the last 140 or so rows. I spent quite a lot of time on it, trying to reduce the number of transclusions and ultimately gave up, hoping that the problem was temporary. I'll note that your last version of the page (http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&ol…) takes almost a _minute_ to appear, while my current version of it (with the data in the page instead of transcluded) takes about 3 seconds. >If the data in the templates is well maintained then it could be used >in the infoboxes on the city pages, then thousands of articles could >display information offset information obtain from IANA. It is. It was just the "List of tz database time zones" that is unable to use them (for the moment).

3 2

Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate
by Tobias Conradi June 6, 2012

June 6, 2012

In Wikipedia several accounts that added Olson/IANA time zone information have been blocked and marked as sock puppets of Tobias Conradi. Since User:Tobias Conradi did not edit since years, because a handful of people once decided to block him, the only evidence for "sock puppeting" is given as "behavioral". Behavioral for the User:TimeOfChange is to edit time articles: http://en.wikipedia.org/wiki/Special:Contributions/TimeOfChange No single talk page edit or anything else. Lately User Royaume du Maroc got blocked, who created: http://en.wikipedia.org/wiki/Time_in_Florida A listing of states that have more than one IANA time zone http://en.wikipedia.org/w/index.php?title=Time_in_the_United_States&diff=49… http://en.wikipedia.org/wiki/Time_in_Idaho Expanding the listing, maybe to create more state specific articles http://en.wikipedia.org/w/index.php?title=Time_in_the_United_States&diff=49… Then User:AlanM1 jumps in, who later in a discussion when User Royaume du Maroc was already blocked writes http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archiv… "... I created some and edited some other "Time in state" articles for the purpose of specifying exactly which counties (or other divisions) are in which time zones. He jumped on it at the same time, apparently prompted by my email to the tz list" - this AlanM1 seems to be on the tz mailing list. I emailed one Alan (an "Alan Mintz") that is on the list showing that it was the other way around, and AlanM1 jumped on it, but AlanM1 did not fix his claim in WP. Does AlanM1 believe Royaume du Maroc did a time travel? BUT NOW THE REAL PROBLEM. AlanM1 is deleting IANA time zone from Wikipedia e.g. Shiprock, South_Pole, Longyearbyen, Ljubljana http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&di… and at the same time introducing | [[ISO_3166-1:|ISO_3166-1:]] | | [[PST8PDT]] into a list that claims to be based on a zone.tab listing. PST8PDT is not in the current zone.tab file. Also the minus signs are changed into hyphen minuses, so that UTC offset articles which use the minus sign are now reached via redirects. Furthermore the order of the elements in that list is not more the same as in zone.tab, and the first column that allowed sorting in that order got removed by AlanM1. Maybe some readers here with an account on Wikipedia can revert the introduced errors and explain to AlanM1 what the errors are. E.g. due to South_Pole removal in the data templates, at http://en.wikipedia.org/wiki/Time_in_Antarctica there is now "[[ISO 3166-1:IANA time zone id not in Template:Tz/country code|IANA time zone id not in Template:Tz/country code]]" Also due to not using the data templates at http://en.wikipedia.org/wiki/List_of_tz_database_time_zones Wikipedia is now open to inconsistency between this list and data display in other places. Before the change the list showed to a wide extend the data contained in the templates, so people could easily check for correctness. If the data in the templates is well maintained then it could be used in the infoboxes on the city pages, then thousands of articles could display information offset information obtain from IANA. That way also the tz mailing list could attract more feedback on time zone changes. It could be a win-win for IANA and Wikipedia. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

time zone abbreviations - French vs English
by Tobias Conradi June 5, 2012

June 5, 2012

was: tz abbreviations / zdump for programmers On Tue, Jun 5, 2012 at 1:43 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > On 06/04/2012 11:39 AM, Boruch Baum wrote: >> Do the French in Quebec have the same >> TZ name and abbreviation as the Anglos there? > > Yes, absolutely. This is a common situation > in many parts of the world. That was someone without giving evidence, it follows Tobias with giving evidence. No they don't universally: HNE vs EST https://www.google.com/search?q=19h00+%22HNE%22+site%3Aqc.ca Two other pairs are: HAEC vs CEST HEC vs CET -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0