I'm a little fuzzy about what you are talking about. If it is the internal IDs (eg "Asia/Shanghai"), they should never contain anything but a very constrained, locale-independent set: A-Z, a-z, space, slash. If you are talking about localized names, like "Heure avancée de Chine" or "中国标准时间" or "Шанхай", those can't be limited in any way because we can't know that the customary form is alphanumeric. But these *don't* belong in the tz database in any event! ‎Mark ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> Cc: "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Sent: Monday, May 09, 2005 12:23 Subject: Re: TZ environment variable

"Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> writes:

...

If the TZ environment variable needs to be checked for mischief-making time zone abbreviations, the same check needs to be applied to values derived from time zone files

Yes, quite right. Presumably the same check should be applied to each.

Another issue is, what check would be reasonable? The simplest check is to restrict the abbreviation to what POSIX requires, namely, N bytes (where 3 <= N <= TZNAME_MAX) that contain only ASCII letters, digits, "-", or "+". A reasonable value for TZNAME_MAX might be 255, assuming the implementation doesn't specify it.

One way we can be more generous is to lower the "3" to "2" (or "1") in the above-mentioned check. I doubt whether it's reasonable to lower it to zero. This would be easy.

If we want to allow other characters in the zone name, it will be a hassle, but one possibility is to relax the character-set restrictions, as follows:

* Every character in the abbreviation must be alphanumeric in the current locale (as specified by LC_CTYPE).

* The following checks are relevent for locales with multibyte encodings:

- The abbreviation cannot have invalid byte sequences. - The abbreviation must end in the initial shift state.

A problem with this more-generous approach is that the locale might change just before localtime() is called; presumably this would require revalidating the zone.

"Mark Davis" <mark.davis@jtcsv.com> writes:

I'm a little fuzzy about what you are talking about.

We're talking about the time zone abbreviation. For example, on my host: $ echo $TZ America/Los_Angeles $ date -u; date Tue May 10 03:58:35 UTC 2005 Mon May 9 20:58:35 PDT 2005 Here we're talking about the strings "UTC" and "PDT". We're not talking about "America/Los_Angeles", or "Pacific Time", or "Pacific Daylight Time", or anything like that. POSIX says time zone abbreviations must be at least 3 bytes, and cannot be more than TZNAME_MAX bytes, and must contain only "alphanumeric characters from the portable character set in the current locale, the plus-sign ('+') character, or the minus-sign ('-') character". In practice this set is just the ASCII letters, digits, "-", and "+". TZNAME_MAX must be at least 6; a value of 255 is common on BSD hosts. The common practice of an abbreviation like "CET DST" is not a portable POSIX time zone abbreviation, for two reasons. First, it contains a space. Second, it's longer than 6 bytes. POSIX requires "CEST" or something like that. Implementations can support abbreviations like "CET DST" as extensions. The question is whether to allow such extensions, including really weird abbreviations such as abbreviations containing newlines, or empty abbreviations. These can cause real problems in practice. Even "CET DST" can cause problems, and various implementations treat it differently. For example: $ date -u; TZ='CET DST8' date # Solaris 8 Tue May 10 04:09:27 GMT 2005 Tue May 10 04:09:27 CET 2005 Ouch! That "CET" looks like a bug to me. Fixed on Solaris 10: $ date -u; TZ='CET DST8' date # Solaris 10 Tue May 10 04:09:40 GMT 2005 Tue May 10 04:09:40 GMT 2005

The tz database says that Kazakhstan has three time zones. I was asked by a correspondent to check that statement. There is evidence that suggests that the two western zones have been consolidated, but it's not conclusive. This is a summary of the evidence; perhaps someone else on the mailing list can find a definite answer. I know that most time zone sites on the internet get their information simply by copying from someone else, so I tried to check sources that I know have independent information. The web page of the Kazakh embassy in the U.K., http://www.kazakhstanembassy.org.uk/cgi-bin/index/55, says that there are two time zones, and that Astana is on UTC+6. The page has no update date, but includes other information dated February, 2005. The web page of the Kazakh embassy to Belgium at http://www.kazakhstanembassy.be/Kazakhstan.asp, on the other hand, shows three time zones (Eastern/Main, Central, and Western). It has a copyright date 2004. The December, 2004 Official Airline Guide (OAG) showed three time zones for Kazakhstan; the current online data from OAG show only two. I believe the OAG gets its data from the IATA SSIM, which in turn gets its data from member airlines. The time zone map in the CIA World Factbook online, dated "3-05", also shows only two zones. However, I can also find CIA World Factbook time zone maps dated "7-03" and "4-01" that show the same two zones, suggesting that the CIA map has been consistently wrong. The "6-99" map shows two time zones but with a different coverage: Qyzylorda Oblysy is shown in UTC+5 instead of UTC+6. Another small piece of evidence for two zones: the Worldtimeserver website has a map (http://www.worldtimeserver.com/current_time_in_KZ.aspx) that apparently shows Kazakhstan divided into three time zones. However, its list only gives two time zones for Kazakhstan (Eastern and Western), and the map for Western only shows two zones. This suggests that the webmaster for that site recently altered the map for Western, but forgot to change the Eastern map to match. It's tempting to think that the UTC+4 zone was switched to UTC+5 at the same time that DST was abolished in Kazakhstan, March 15, 2005. The Kazakh embassy in the U.S. has a newsletter on its website with an article about the abolition of DST (http://www.kazakhembus.com/031705.html), but it doesn't mention time zones being consolidated. If two zones is correct, Asia/Aqtau and Asia/Oral should be changed from UTC+4 to UTC+5 in the tz database. The effective date for this change was probably quite recent. -- Gwillim Law

I found more concrete evidence: http://eng.gazeta.kz/art.asp?aid=47715 If I'm reading it right, the article says that the UTC+4 / UTC+6 division is the eastern border of the Aktobe province (Aktyubinskaya Oblast'). The article says amongst others: "... in the west of Kazakhstan there will be the Astana time plus 2 hours". I think "minus 2"? In my interpretation this means that the following provinces are on UTC+4: Zapadnyj Kazakhstan/Ural'skaya Oblast' Mangistauskaya Oblast' Aktyubinskaya Oblast' (Aqtöbe) Atyrauskaya Oblast'/Gur'yevskaya Oblast' And on UTC+6 the rest: Almatinskaya Oblast' Akmolinskaya Oblast'/Tselinogradskaya Oblast' Zhambylskaya Oblast' Karagandinskaya Oblast' Kustanayskaya Oblast' Kzyl-Ordinskaya Oblast' Yuzhnyj Kazakhstan/Chimkentskaya Oblast' Pavlodarskaya Oblast' Severnyj Kazakhstan Vostochnyj Kazakhstan Mentioned article also infers when the transition took place: at the moments of DST switch. Some provinces stayed on summertime UTC+6 (Kostanai and Kyzylorda), another province (Aktobe) didn't go to (the now abolished?) summertime and stayed on UTC+5. So, if I'm reading the last statements in the article correctly, they imply UTC+5 and UTC+6 time zones. In the beginning of the article however it is clearly stated that Kazakhstan "is situated in the fourth and fifth time zones in relation with Greenwich". HELP!! Oscar van Vlijmen 2005-05-13

In the beginning of the article however it is clearly stated that Kazakhstan "is situated in the fourth and fifth time zones in relation with Greenwich". HELP!!

Oscar van Vlijmen 2005-05-13

It appears that we're still uncertain about the current state of Kazakhstan's time zones. I've tried to gather all the evidence we've seen so far and draw the most likely conclusions. Excuse me if this message is too verbose or detailed. Since there are so many contradictions in the evidence, I had to reason on a very basic level. The main sources I looked at were: A. http://www.kazsociety.org.uk/news/2005/03/30.htm - Kazakhstan Society in the U.K., based on embassy report B. http://www.kazakhembus.com/031705.html - Kazakhstan Embassy in the U.S. (same text as the previous source) C. http://eng.gazeta.kz/art.asp?aid=47715 - gazeta.kz report dated 2004-07-26 D. http://www.inform.kz/showarticle.php?id=86783 - Kazinform report dated 2004-07-27 at 14:07 E. http://www.kazakhstanembassy.org.uk/cgi-bin/index/55 - Kazakhstan Embassy in the U.K. F. http://www.kazakhstanembassy.be/Kazakhstan.asp - Kazakhstan Embassy in the Belgium G. The Official Airline Guide online H. The CIA World Factbook time zone maps from various years The regions (oblysy) of Kazakhstan that are mentioned can be divided into four groups, listed roughly from west to east below. 1. 47° to 56° E: Atyrau (a.k.a. Ateransk, Gur'yev), Mangghystau (Aktau, Mangyshlak, Shevchenko), and West Kazakhstan (Batys Qazaqstan, Oral, Ural'sk, Zapadno-Kazakstan) regions. Tz database equivalent: Asia/Aqtau and Asia/Oral (both of which have been on UTC+4 since 1995). 2. 54° to 64° E: Aqtöbe (Aktobe, Aktyubinsk) region. Asia/Aqtobe, UTC+5 according to the tz database. 3. 58° to 67° E: Qostanay (Kustanai) and Qyzylorda (Kzyl-Orda) regions. Asia/Qyzylorda, UTC+6 4. 63° to 87° E: Remainder of Kazakhstan, including Astana, the capital, and Almaty. Asia/Almaty. UTC+6 All of these areas have followed RussiaAsia DST rules since 1992 or earlier, until the termination of DST in 2005. In the first place, be aware that when a Kazakh source says "plus" it may mean "minus". For example, C says, "in the West of Kazakhstan there will be the Astana time plus 2 hours". There is no reason on earth why western Kazakhstan would have a later standard time than eastern Kazakhstan. Perhaps the logic is that when it's noon in Astana, you have to wait another two hours before it's noon in West Kazakhstan. A and B say that the government issued a decree on 2005-03-15 cancelling daylight saving time. None of the other sources seem to be in disagreement. There are also many sources that agree that Astana was and still is on UTC+6 as its standard time. C and D both say that one of Kazakhstan's three time zones will be eliminated. D says pretty clearly that, after the change, group 1 will be two hours ahead of group 4. Its most ambiguous statement is, "Henceforth Aktobe oblast is to enter into the given time belt," where it's not entirely clear which time zone is the "given" one. The previous sentence was about the time zone of group 1. If that is the "given time belt", then group 2 will be placed in the same time zone as group 1. C has the most information. It also has two contradictory statements. It says, "The order established that the territory of RK is situated in the fourth and fifth time zones in relation with Greenwich", but also "...in the West of Kazakhstan there will be the Astana time plus 2 hours." Since there is ample evidence that Astana's standard time is UTC+6, the "fifth time zone" is very likely a typo. C also says, "The time zones will be divided by the Aktobe province Eastern border...." The only explanation consistent with Kazakhstan's geography is that groups 1 and 2 will form one time zone and groups 3 and 4 will be the other. Next, C says, "Previously there were 3 time zones in Kazakhstan. [We knew that.] But in Kostanai, Kyzylorda, and Aktobe provinces the Astana time plus 1 hour functioned. [This says that groups 2 and 3 were one hour earlier than group 4, i.e. UTC+5. The tz database says that group 3 has been on UTC+6 since 1992.] However the daylight hours were not used efficiently in those provinces. The Astana time was functioning in fact in Kostanai and Kyzylorda provinces to simplify the administrative work." The explanation seems to be that group 3 was de jure UTC+5, de facto UTC+6. Finally, C says, "To introduce changes in the measuring of time there will be no transfer to winter time in Kostanai and Kyzylorda province [group 3] in 2004 and to summer time in Aktobe province [group 2] in 2005." Is it now talking about de jure or de facto time in group 3? Remember, C is dated July 2004, when DST was in effect, so local clocks in group 3 would have been set to UTC+7 de facto. Group 4 set its clocks back from UTC+7 to UTC+6 on 2004-10-31. If group 3 did not set its clocks back, it would still be on UTC+7, an hour later than Astana, which is absurd. So the sentence must be referring to de jure time in group 3. That means that group 3 was on UTC+6 during the summer of 2004 and remained on UTC+6 when group 4 returned to its standard time of UTC+6 in October 2004. Groups 3 and 4 would then stay on the same time ever after. As for group 2, if it didn't set its clocks ahead an hour in spring 2005 while group 1 did, the two groups would then be in synch. The end result would be that groups 1 and 2 would have UTC+4 as their standard time, and groups 3 and 4 would have UTC+6. This fits in well with the conclusion I drew from D. However, when C was written, no one knew that Kazakhstan was going to abandon DST. As it turned out, group 1 didn't turn its clocks ahead in spring 2005, which spoiled the plan to bring it into synch with group 2. What is the backup plan? I don't have any evidence on that point, but if I were in charge, I would have decreed that group 2 should set its clocks back an hour (from UTC+5 to UTC+4) on 2005-03-27 at midnight. Summarizing my conclusions from these sources, a new row should be added to the Asia/Aqtobe zone, with 4:00 as the offset from UTC. The previous row should have an end date of 2005 Mar 27, if my guess is right. Source E is fully consistent with these conclusions. F only says that Kazakhstan has three time zones, and since its copyright date is 2004, we can assume that it was written before these changes were decided on. G agrees that there are two time zones, and that the western one consists of groups 1 and 2; however, it says that the time in the western zone is UTC+5, not UTC+4. Earlier printed versions of the Official Airline Guide showed Kazakhstan with three time zones, consistent with the tz database. H is noncommittal about DST, but it shows Kazakhstan divided into two zones, with groups 1 and 2 on UTC+5 and groups 3 and 4 on UTC+6. Therefore, G and H are in agreement, and they say that the western zone is UTC+5 in contradiction to the other sources which say it's UTC+4. One fact that calls H into question, though, is that it has been wrong in the past. As far back as I've checked, the CIA World Factbook time zone maps have split Kazakhstan into only two zones, UTC+5 and UTC+6. The western zone consisted of groups 1, 2, and 3 in the 1992 edition. Later on, Qostanay (part of group 3) was switched to the eastern zone; then, between the 1999 and 2000 editions, Qyzylorda (the remainder of group 3) was also switched to the eastern zone. The current edition's map is dated March 2005, but it doesn't show any changes in Kazakhstan since 2000, so it may not reflect recent changes. That's the best I can do for now. If other sources turn up, we may have to reconsider again. -- Gwillim Law