- tz - lists.iana.org

localtime.c bugs
by Doug Bailey July 11, 2012

July 11, 2012

I've started working with tzcode2012b and I've run into a couple of issues. The first: in testing, I found that if I set a timezone like "CST6", the tzname[] array would not be initialized. Digging into it, I found that settzname[] depends on having transition rules for the zone, but a zone like "CST6" will only be created with a single type and no transitions. To work around that one I've added the following code to initialize the tzname[] array from the ttis array before running through the types array: + for (i=0; i<sp->typecnt; i++) { + const struct ttinfo * const ttisp = &sp->ttis[i]; + tzname[ttisp->tt_isdst] = &sp->chars[ttisp->tt_abbrind]; + } /* ** And to get the latest zone names into tzname. . . */ for (i = 0; i < sp->timecnt; ++i) { register const struct ttinfo * const ttisp = &sp->ttis[ sp->types[i]]; The second has to do with our environment. We have an unfortunate time_t definition: an unsigned 32-bit number. The tzload code attempts to take unsigned time_t values into account, but if I'm not making a mistake understanding the way it's supposed to work, I think it has a few problems. First, the loop over (i < sp->timecnt - 2) means that in comparing ats[i] > ats[i+1], you never compare ats[sp->timecnt-2] > ats[sp->timecnt-1]. This means that if all the transitions except the last are pre-epoch (negative number), the list doesn't get trimmed down. Second, with that fixed, there are still problems with zones that only have pre-epoch transitions (e.g. America/Regina). In such a case, the ats[i] > ats[i+1] case never triggers, so you're left with a list of ats[] values that aren't valid -- they're negative numbers in a system with an unsigned time_t. This is rather uglier. I've included my fix for what it's worth, but you can probably work out something better. One thing to note: I try to preserve the last pre-epoch transition, to handle situations where there's a large gap in transitions between the start of the epoch the the first post-epoch transition. /* ** Out-of-sort ats should mean we're running on a ** signed time_t system but using a data file with ** unsigned values (or vice versa). */ #if 1 for (i = 0; i <= sp->timecnt - 1; ++i) if ( (i < sp->timecnt-1 && sp->ats[i] > sp->ats[i + 1] ) || (i == sp->timecnt-1 && !TYPE_SIGNED(time_t) && sp->ats[i] > INT32_MAX) ) { if (TYPE_SIGNED(time_t)) { /* ** Ignore the end (easy). */ sp->timecnt = i+1; } else { /* ** Ignore the beginning (harder). */ register int j; // keep the record right before the epoch boundary, but // tweak it so that it starts right with the epoch sp->ats[i] = 0; // move everything back... if (i > 0) { for (j = 0; j + i < sp->timecnt; ++j) { sp->ats[j] = sp->ats[j + i]; sp->types[j] = sp->types[j + i]; } sp->timecnt = j; } } break; } #else for (i = 0; i < sp->timecnt - 2; ++i) if (sp->ats[i] > sp->ats[i + 1]) { ++i; if (TYPE_SIGNED(time_t)) { /* ** Ignore the end (easy). */ sp->timecnt = i; } else { /* ** Ignore the beginning (harder). */ register int j; for (j = 0; j + i < sp->timecnt; ++j) { sp->ats[j] = sp->ats[j + i]; sp->types[j] = sp->types[j + i]; } sp->timecnt = j; } break; } #endif I appreciate any assistance with this. Doug

4 4

DST was probably observed in Detroit in 1968
by Steffen Thorsen July 9, 2012

July 9, 2012

It looks like the database has incorrect time for Zone America/Detroit during 1968. In Shanks it is standard time through all of 1968 (and that is also given in the database), but newspaper articles from that same year seem to contradict that. Basically, it seems that Michigan did observe DST the same dates as the rest of the US in 1968. (Maybe with the exception of Berrien county, I have not investigated this exception further since it is before 1970). One source is the Daily Globe, Friday, November 1, 1968 (in Ironwood, Michigan), it has an article written by the AP: (page 14, "Confusion Abounds Over Simple Daylight Time Vote"): Relevant quote from that article: "as a result Michigan has gone on savings time this summer and last." Longer excerpt telling more about the background: The Federal Uniform Time Act of 1966 gave any state permission to exempt itself from fast time if it acted before April 29, 1967, using its normal legislative process to enact an exemption law. Michigan did that. In 1967 the Legislature approved and Gov. George Romney signed a bill providing that all of Michigan would remain year around on Eastern Standard Time, as most of it had since the 1940s. The Citizens Research Council of Michigan says Hawaii was the only other state to pass such an exemption, although Kentucky and Alaska were granted temporary exemptions. Backers of savings time, however, circulated referendum petitions challenging the exemption law and succeeded in putting it on the ballot. Then: success suspended the law, and as a result Michigan has gone on savings time this summer and last. Snarled up with the Daylight Tune issue is another section of the Uniform Time Act which put all of Michigan's Lower Peninsula on Eastern Time and the entire Upper Peninsula on Central Time. The two eastern counties of the U.P. have ignored the law and observe Eastern Standard and Eastern Daylight Time like the Lower Peninsula. Best regards, Steffen Thorsen - timeanddate.com

1 0

Relative to Beginning of Month or to End
by Marvel, Jim (CPCOE) July 6, 2012

July 6, 2012

Did a zdump. How to tell if timezone DST rules indicate counting relative to beginning of month ("2nd Tuesday") or to end of month (last Sunday for example). Extreme newbie. Does this info live in the source code?

2 2

Russia may move it's clocks back 1 or 2 hours
by Alexander Krivenyshev June 28, 2012

June 28, 2012

According to different news (in Russian), Russian State Duma is considering the introduction of a permanent winter time with moving its clocks back 1-2 hours. The bill on the transition from summer to winter time will be finalized and submitted to Russian State Duma in early September. http://www.worldtimezone.com/dst_news/dst_news_russia44.html Alexander Krivenyshev, http://www.worldtimezone.com

1 0

Coordinates for America/Sitka in zone.tab?
by OvV_HN June 26, 2012

June 26, 2012

In reply to: [tz] Coordinates for America/Sitka in zone.tab? Alan Mintz Alan_Mintz+TZ_IANA at Earthlink.net Tue Jun 26 07:26:52 UTC 2012 I was under the impression, from the few that I look at on a map, that the coordinates in zone.tab were supposed to be approximately where the name of the zone and the most well-known place is. America/Sitka puzzles me, though. At 57 10 35, -135 18 07, the point is in the water of Katlian Bay, about 150m offshore of a seemingly uninhabited area. The point is 14 km from Sitka. Should this be changed to 57d03'06", -135d20'19"? Reply: Your reference? The Geonames server: http://www.geonames.org/search.html?q=sitka&country=US says: United States, Alaska Sitka City and Borough seat of a second-order administrative division population 8,881, elevation 8m N 57° 3' 11'', W 135° 19' 48'' Which seems better than a place with wet feet! So, please change zone.tab someday..... Oscar van Vlijmen

2 1

Coordinates for America/Sitka in zone.tab?
by Alan Mintz June 26, 2012

June 26, 2012

I was under the impression, from the few that I look at on a map, that the coordinates in zone.tab were supposed to be approximately where the name of the zone and the most well-known place is. America/Sitka puzzles me, though. At 57 10 35, -135 18 07, the point is in the water of Katlian Bay, about 150m offshore of a seemingly uninhabited area. The point is 14 km from Sitka. Should this be changed to 57d03'06", -135d20'19"? -- Alan Mintz <Alan_Mintz+TZ_IANA(a)Earthlink.net>

1 0

Bug report: "Asia" timezone
by Boruch Baum June 19, 2012

June 19, 2012

I was recently showing off ... and I entered the following command $ date && TZ=Asia/Moscow date Tue Jun 19 15:48:14 EDT 2012 Tue Jun 19 19:48:14 Asia 2012 My initial reaction, besides some embarrassment at getting the continent wrong (and most of Russia's timezone are in Asia), is that this is a bug in the coreutils date command. However, I thought it would be of interest to members of the list. It's a double bug. It's printing out a non-existent timezone, and it's using GMT for "Asia" -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

2 1

tz abbreviations / zdump for programmers
by Boruch Baum June 19, 2012

June 19, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings y'all, I have a bit of a long (inaugural) post here to describe my interest in joining this list, and what I might be able to contribute to the greater glory of tz-correctness. BTW, as part of my 'due diligence' before posting this, I read/scanned a selection of the collection of detailed comments in the glibc-2.13/timezone files, as well as the timezone entry in glibc-2.13/FAQ. I'm very glad those comments are there. CONTENTS ======== 1] The app/library I develop/maintain 2] End users' stubborn insistence on using tz abbreviations 2.1] zone.tab modification proposal 2.2] zone.abbr.tab proposal 3] The 'zdump' programmer's function I 'need' to write 1] The app/library I develop/maintain ===================================== libhdate is a FOSS collection for Hebrew time/date 'stuff', for which time zone data and location coordinates are important because: 1) we have about a dozen significant astronomical times-of-day that need to be mapped to a correct local clock time at any particular location; 2) users want that information for future and past dates, and; 3) users want that information for locations in other parts of the globe. This FOSS collection is under active development and versions are available from sourceforge and the Debian GNU/Linux repositories. There are unrelated, closed-source, alternatives available (eg. kaluach for windows and java, and dostagfarlinux for, um, linux). 2] End users' stubborn insistence on using tz abbreviations =========================================================== ... and who can blame them, when that's all they hear in the media. This leaves me in a bind, because if I accept a tz abbreviation as a user input, I have two undesirable options: 1) I could scan ALL the ~420 tzif files for matches and, if I discover that the tz abbrev is not unique, either make an educated guess (based upon the user's locale definition which often will include a country code and a language) or prompt the user for clarification; or 2) I could pre-compile a list that suits my parochial needs, and update my list anytime the tzdata package is updated (and still have to occassionally guess or prompt the user). Then I said to myself, "self, you can't be the only one out there facing these users - go consult and find a global solution". Following are two proposals. Neither may be perfect, but each may make life alot easier for many... 2.1] zone.tab modification proposal =================================== Add a new column/field to this file, in the format: {{;xxx:nnnnn;xxx:nnnnn;...;}} where: xxx is a tz abbreviation nnnnn is the UTC offset for that abbreviation. The use of ";", ":", and braces are to simplify the task of parsing the data programmatically. Advantages: 1) All information for a timezone on a single line (ie. in a single record). 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) Disadvantages: 1) Long line(record) length 2) Messing with the format of an existing file, upon which others may depend 3) Requires change to whatever script/program is used to compile the file for release 2.2] zone.abbr.tab proposal =========================== Create a new text file, say /usr/share/zoneinfo/zone.abbr.tab, sorted by tz abbreviation, with a format like: tz_abbrev country_code localedef useful for setting $LC_TIME and for language matching is_dst if yes, this would have the abbreviation of the non_dst version of this tz. utc_offset historical_only (y/n) - ie. whether currently in use. full_name of the abbreviation, not of the 'real' tz name. Advantages: 1) Easy to find matches for users' pesky (short and convenient-to-type) tz_abbr 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) 3) Includes additional useful information (is_dst, historical_only, full_name, locale_def) 4) Doesn't mess with existing files Disadvantages: 1) It's a new file. 2) Requires new script/program to compile the file for release 3] The 'zdump' programmer's functiion I 'need' to write ======================================================= This section isn't directly related to the above. I don't NEED to write a 'zdump' programmer's functiion; I WANT to, because I remember when a 4Mhz clock speed was wicked fast, and using the current glibc time functions for my libhdate collection would be tremendously wasteful, although today's users will probably never notice. For this section, the reason I want to consult with members of this list (and I appreciate you having read this far) is to make the function as universally useful as possible (it will be FOSS/GPL3+) . My current plan is: int zdump( /// returns TRUE on success, FALSE on failure const char* tzname, /// fully-qualified time-zone name /// (eg. Asia/Baku) const time_t start, /// seconds from epoch to be scanned const time_t end, /// seconds from epoch to be scanned int* num_entries, /// upon successful return, int will contain /// the number of dst transitions + 1, /// for the interval 'start' to 'end'. /// The first entry will always be the /// tz state at time_t start. /// Returns 0 on failure. void* return_data /// upon successful return, will contain a pointer to a malloc()ed space of /// 'num_entries' of 'tzinfo' data, as /// described below, sorted in ascending /// chronological order. /// Returns NULL on failure. ) tzinfo { time_t start /// seconds from epoch int utc_offset /// in minutes, or maybe seconds. char is_dst /// 0/1 char[] tz_abbrev /// const char end_mark /// '\0' } - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPzM3HAAoJEDvrUfDmCx9LbJ4P/RMD+8KWkXxrLtpivyQVz6Yv h88mWjwfeTpb7laT4yeg726YYUQEDfhueLFELRTpxR6aAIAW7fBZEu6UwEMSsxHe UaQdx/xc/03aei/AG6z31u0C+arA40qs8twxEw5pdyHfvBxhQh0YOxO+dl01+zmg w4Y+Mlyd72QmAZ+pdIc5l2L/nTh9L+YnlmPxsXoomYSTh+9kigOxS5JZVMu2sYy6 7FGMj+mybrtru12qwJmoFG2hNjVgy0zKSuJ1HOXmqi5JKBNthlsfkyV4E9vzSGWC PkkbI8R0adGnqKa9faHQxFG+jV+K5Fjscr3eabBi8IYHG+cGYOL6vD0KkNFbHRQf wLRGpkkMjoJm9cxJ7f17wcQFtYFKjcDLIqqtDuT7LhHJ7iF2x4lTqd4YjvpA6rqN fcD+4TNfm8Na5bNbKNJqvWy+Od46wSNqFOiUf9NQaWsUZx/yiXjw1Sl4Jqi7/2Sg A3rc2bcw02Co80bWA+lsMbZUL5NJlQAdfWCKe7xafdILX8PPbe0CaTHzNUFd4vR9 70AJsq6teBivVHossldNlQfsK+S4HmcSMGPt1AuANjGUv0ZoCveR71Ewt0D2wbi4 hSEaSI/P3MVSsFRMJZIoMXlFTuF6d6qItoRvmHrLdU2u5f1+Kjbt7tH0eMOrcdm9 BUi/N3QtrJkU6vWXjLal =n4Kd -----END PGP SIGNATURE-----

16 30

Re: [tz] Are these valid timezone definitions?
by Tadashi Abe June 15, 2012

June 15, 2012

Hi, sorry to interrupt with newbie question. david singleton wrote: >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? Now I'm testing DST start/end by setting the actual system clock as same as the above method and get the same issue. 1. export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" 2. set system clock just 5 seconds prior to DST [start|end] 3. 5 seconds later, check if switch between DST and STD occurs, but not. As the comment from Zefram, it works when I check date with -d option. http://mm.icann.org/pipermail/tz/2012-June/018059.html >It's always difficult to test timezone offset issues when you're >stating the test times in local time. By the way, your testing method >of modifying the system clock is problematic. It's much better to use >the -d option of GNU date to display a particular time without touching >the clock. Why doesn't it work well when I try to test by modifying the actual system clock? -- Tadashi Abe

3 2

Re: [tz] Patch - America/Los_Angeles zone comment
by Steve Jones June 14, 2012

June 14, 2012

At 13:30 6/9/2012, OvV_HN wrote: >Regarding Malheur county in Oregon: you could add: the _northern_ >part of Malheur county. Here is an image that reflects the borders of Malheur county as well as the time zone border in the area: <http://ontimezone.com/images/malheur.gif>http://OnTimeZone.com/images/malheur.gif The portion of the time zone border that bisects Malhuer county starts on the western border of the county at the southwest corner of T. 35 S., R. 37 E., and runs due east to the eastern border of the county. There is no obvious manmade, political, or geographic feature that further reflects or indicates that portion of the time zone border. Cheers, Steve Jones OnTimeZone.com

3 2