tz abbreviations / zdump for programmers
-----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-----
Boruch Baum <boruch_baum@gmx.com> wrote: |My current plan is: |[.] |tzinfo { | time_t start /// seconds from epoch | int utc_offset /// in minutes, or maybe seconds. | char is_dst /// 0/1 I would suggest to you using a different field for that, which, if not 0, would implicit mean "is daylight saving". We have a 'save_secs' field instead, meaning the time to save in seconds (we only use seconds, also in our utf_offset, which thus refers to the unadjusted offset). Sometimes nice. | char[] tz_abbrev /// | const char end_mark /// '\0' Ah, and we have a hashmap of all possible zone abbreviations, and only store the index of it in our "RuleDat". Less compact, but one can store the string somewhere nearer as necessary. (Due to filename length issues and data compactness we've used a single binary database approach.) Just my one cent. --steffen Forza Figa!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2012 11:36 AM, Steffen Daode Nurpmeso wrote:
Boruch Baum <boruch_baum@gmx.com> wrote:
|My current plan is: |[.] |tzinfo { | time_t start /// seconds from epoch | int utc_offset /// in minutes, or maybe seconds. | char is_dst /// 0/1
I would suggest to you using a different field for that, which, if not 0, would implicit mean "is daylight saving". We have a 'save_secs' field instead, meaning the time to save in seconds (we only use seconds, also in our utf_offset, which thus refers to the unadjusted offset). Sometimes nice. Accepted: utc_offest in seconds and is_dst changed to save_secs Thanks.
| char[] tz_abbrev /// | const char end_mark /// '\0'
Ah, and we have a hashmap of all possible zone abbreviations, and only store the index of it in our "RuleDat".
I don't see this hashmap. How can I find it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPzPdZAAoJEDvrUfDmCx9LMlwP/i476t/OgUgEsry3OoHvy2Q9 eCqmyIAP9yDl+sC0olkNNp0lOqbBBeWMACs8jme0dn0e/rngMvMhGnWDQiax6u5/ Gr6eisJXuB4Oo6xFyhYWPT5WwyGBMoQ5+Zx1iZGfl4ET4dypRQi+Sq0Um/+Hc3pj wvbeHXDiqLpXODnl+QrpZ4O2+o1OIHCKWxvGRCOK/Ev0VeBikPxyR+NDSBcFO7Qv ddYxu9Bq3KqaIeTYKOt9derGchNS60PlH3B/aufDjdS+khZcFsXfcgT3PTTlVq1H 7Np1IimMaBSHxz9aR9iSG1OWI+ZoXrZgUdGsI7s+qAUVfqAtsZ8vyRRIL4eWzl9o r2yEeltXP0PvU57Ed7Hvxc6ZUFETIoJ2zHNl+MBWfRZR1gIukl6EjCgsrH4yY+xb 19Taoq867hbos0DEHW0RxLKrIy+0Q9/IaMX8I47NDSiHoZjmi/Z8VLpgKQ7AuroS ZA7jImgJw+tZ47bbjDH8LP9hvi2zPSf0VmEBXx1Yky8tn5QcqnzHx9YvKQAaYYPK EOCx8o/OqlBAaalTxsAEeoMdFbgC8qv7s+zATwTUkQbIqa9KrPbCR/JdUaJmHYa6 Nqpf2kk5npStQTd15/ktROkmMTbFGxqaJ04Sy5gat7T2sqyQDeAxkuApa6zXnezc +rP7jdA7cWfASCLnQjqL =8K97 -----END PGP SIGNATURE-----
Thanks for the email. Some comments:
2.2] zone.abbr.tab proposal
This seems better, since the file could be maintained automatically from the existing data, with a new script or whatever. I didn't understand this table's "localedef" column though; isn't the tz info independent of locale? Or are you anticipating a future feature in which time zone abbreviations depend on locale?
int zdump( /// returns TRUE on success, FALSE on failure
How about instead having a little function that, given a time, finds the next (or the previous) transition time? That would allow iterations through transitions that'd be much easier than poring through the output of the proposed 'zdump' function, with no need to worry about malloc and free.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2012 01:00 PM, Paul Eggert wrote: > Thanks for the email. Some comments: > >> 2.2] zone.abbr.tab proposal > > This seems better, since the file could be maintained automatically > from the existing data, with a new script or whatever. OK. > I didn't understand this table's "localedef" column though; isn't > the tz info independent of locale? Or are you anticipating a > future feature in which time zone abbreviations depend on locale? I'm not terribly certain, since I'm new to this myself. My considerations / fears were: 1) having a way to know how the 'owners'/residents of a timezone format their time/date information. 2) multilingual zones - eg. Do the French in Quebec have the same TZ name and abbreviation as the Anglos there? 2) multi-character set zones - eg. Israel, where both Arabic and Hebrew are official languages (and English isn't) - Do the locals use their native character set representations of the timezone abbreviation and name? I would want to respectful of that, to the extent possible. In the case of Israel, I remember dst referred to only as שעון קיץ. BTW, I made one important omission in my proposal for zone.abbr.tab - I left out a field for the tz_name (eg. Asia/Baku). Also, for the parochial need of my libhdate collection, it would be useful to also include on each zone.abbr.tab line the coordinate information already present in the zone.tab file. >> int zdump( /// returns TRUE on success, FALSE on >> failure > > How about instead having a little function that, given a time, > finds the next (or the previous) transition time? This sounds familiar. It may be that I saw that approach being taken in the current codebase. This would not be optimal for me (see below), but if there is a need for it, I could do it also. > That would allow iterations through transitions that'd be much > easier than poring through the output of the proposed 'zdump' > function Here I disagree because: 1) with your approach, each iteration through transitions would require a separate call to the function. My approach has the advantages of being only a single call, a single file open and parse, and an immediate indication of how many transitions to expect over the interval being processed. 2) I'm presuming that the caller will be processing dates in either chronological or reverse-chronological sequence, so it should be very simple to work with the output. I could provide a snippet on the man page. 3) Your suggestion to return the next transition wouldn't be useful for a user who already knows the range of date/times she wishes to process, if that next transition is out of her desired interval. The 'zdump' proposal, in that case, would return just the information required. BTW - the current man page for zdump(1) omits the loyear,hiyear option. Compare the 'man 1 zdump' with 'zdump --help' - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPzQD4AAoJEDvrUfDmCx9LplwP/3nJzMJqfAKP5fhaVUzZxMbE fDOr8W/k9eqJ8K78jkb5MC4JfzVd7nmCIHccl+AoHsTmLrqYjL+otkjxyEjgtga/ BwsA05Ap0UPGjoisOuN5UVBRKWOyZUxFFOVv6U+WRRjLw+6SC/UQ43yspHNcpcti iyet2P6qs25k1SRKYKz9PqeIpxKGuUbclLm3qlIK2wrkQuowmHmnaR60vgfmBshF LUbBWUHf8aVs9GvW+wGyfSNkS/EhylxRHhJhYmAgjLFjDXu4jLzj67cSWvn/SAR9 mU7qdjA0UA8DcUKOG8C9at2bAjA/5nxhMqI5eFm03ZPLjQI6Anajh0rh2JucAWzj y2HwihioFrwCTqUX+59PO0BjtrMH2kdIA5c5jd4z27Wq9zmlVJobA8VMGr3mphqE K1vO/rE10dtpy5uAnoZ+Rj4S3T9yX/bIb/rzN21lYhuktDEvxss9JfgzhBsdMvg9 2DCj9lmAVsvUeBjwidm+XpomKxKPC3dYES9kydrArgT+ZdBPMcQD2heZ2f9rvFIi 0A1t8Y8XJe8iZlcfcr/4ymXWwX50xOAZ0zz/9iWbaS3LJo9V91hQtaTTwqK94PoW IlsB2mdfE2Rk8ykVYijkxdmMwQJJkt4VNtusS0Mbudnz5lDCgY1BqE9TOSJ/cBo+ 4RE0ZBOPoRC2K71ExmMh =0LHE -----END PGP SIGNATURE-----
On 2012-06-04 17:43, Paul Eggert wrote:
On 06/04/2012 11:39 AM, Boruch Baum wrote:
Do the French in Quebec have the same I am sure Paul read this as "different"^ TZ name and abbreviation as the Anglos there?
French in New Brunswick (officially bilingual like Canada) and the rest of Canada would also use the same abbreviations and names.
Yes, absolutely. This is a common situation in many parts of the world.
Canadian English and French Time Zone Abbreviations and Names PST/PDT Pacific S/D Time HNP/HAP Heure Normale/Avancée du Pacifique MST/MDT Mountain " HNR/HAR " des Rocheuses CST/CDT Central " HNC/HAC " du Centre EST/EDT Eastern " HNE/HAE " de l'Est AST/ADT Atlantic " HNA/HAA " de l'Atlantique NST/NDT Newfoundland " HNT/HAT " de Terre-Neuve
Hi all, I have been lurking here for about 6 months and have searched the archives and read the docs and the code and I still cannot find an answer to this question: Is there any version information in the tz source? I grepped it all for the words 'version' and '2012b' and got nothing. I need to build compile tz data for WIndows and would like to grab the version from somewhere other than the name of the tar file. I can't see any way to tell what version of zoneinfo is in use. Thanks in advance, Donald -- Donald [|] A bad day in [] is better than a good day in {}
Individual files, e.g. ftp://ftp.iana.org/tz/data/northamerica seem to have version information, albeit not labeled as such. Current for the former is "8.54". Tobias On Tue, Jun 5, 2012 at 4:43 PM, Donald MacQueen <dmacq@erols.com> wrote:
Hi all,
I have been lurking here for about 6 months and have searched the archives and read the docs and the code and I still cannot find an answer to this question:
Is there any version information in the tz source? I grepped it all for the words 'version' and '2012b' and got nothing. I need to build compile tz data for WIndows and would like to grab the version from somewhere other than the name of the tar file. I can't see any way to tell what version of zoneinfo is in use.
Thanks in advance,
Donald
-- Donald [|]
A bad day in [] is better than a good day in {}
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 06/05/2012 07:43 AM, Donald MacQueen wrote:
I need to build compile tz data for WIndows and would like to grab the version from somewhere
If you're in charge of the source, you can copy the version number yourself into some location, and use that. If someone else is in charge (e.g., you're using some random library), then there's no guarantee you're using tz source as opposed to an independent copy. It might be nice to have a better way to get version number, though I'd say it's more important to do that for the data than for the source code.
On 6/5/2012 11:59 AM, Paul Eggert wrote:
On 06/05/2012 07:43 AM, Donald MacQueen wrote:
I need to build compile tz data for WIndows and would like to grab the version from somewhere If you're in charge of the source, you can copy the version number yourself into some location, and use that. I am in charge in that I will be building the compiled tz data from the tzdata source I get from iana.org.
So are you saying that there is no automatic way (in some script that runs zic) to get the version number, but that I have to copy it manually from the tzdata file name? That's ok with me. I just wanted to know if I overlooked something. Thanks for the reply.
If someone else is in charge (e.g., you're using some random library), then there's no guarantee you're using tz source as opposed to an independent copy.
It might be nice to have a better way to get version number, though I'd say it's more important to do that for the data than for the source code.
-- Donald [|] A bad day in [] is better than a good day in {}
On 06/05/2012 09:20 AM, Donald MacQueen wrote:
So are you saying that there is no automatic way (in some script that runs zic) to get the version number
Not exactly; if you have a script, the script can get the version number from the file name. It's just that the version number is in the file name, not in the file contents.
Paul Eggert <eggert@cs.ucla.edu> writes:
Thanks for the email. Some comments:
2.2] zone.abbr.tab proposal
This seems better, since the file could be maintained automatically from the existing data, with a new script or whatever. I didn't understand this table's "localedef" column though; isn't the tz info independent of locale? Or are you anticipating a future feature in which time zone abbreviations depend on locale?
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. Thanks, PM
Boruch Baum wrote:
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).
This seems the wisest course, if you're committed to accepting abbreviations on input. You can automate the trawl through the tzfiles, to pick out the abbreviation meanings that are relevant to your application. Run the program once, each time tzdata is updated. Then when your application gets an abbreviation as input you do just one quick lookup in the table that you generated. For any more general approach to using abbreviations as input, each specific application still needs to determine its own approach to disambiguation. Maybe it must provide some disambiguating hints, such as a range of years or a continent. Maybe ambiguities should be resolved by asking a human. Also, there's fundamentally more than one thing you can do with an abbreviation as input: do you want to determine a specific geographical timezone, or just an offset? It all depends on the application. So it's not awfully feasible to provide one table that's applicable to most users of abbreviations. Have a look at <https://metacpan.org/release/App-olson>, a querying tool. See what you make of the output from queries like "olson list i@now o@now". It doesn't support searching for an abbreviation anywhere in a time period, but I'm intending to add that in the future. I think some tool like this would be of benefit to abbreviation users. -zefram
On 04/06/12 17:02, Boruch Baum wrote:
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). I would ask the user.
Yes, the users are stubborn and will expect "your silly app" to "perfectly know" what is, for instance, "PST timezone". I'd throw them a dialog requesting clarification if they mean - Pacific Standard Time, UTC−8:00 - Pakistan Standard Time, UTC+5:00 - Philippine Standard Time, UTC+8:00 Maybe with a "By PST I always mean this one" checkbox. If you try to guess, you will sometimes "guess wrong", and a smart program taking bad decisions is worse than a dumb program you need to guide. Also, in the example above you will discover that English is official language in the three countries... :-)
On 04/06/12 21:45, Ángel González wrote:
On 04/06/12 17:02, Boruch Baum wrote:
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). I would ask the user.
Yes, the users are stubborn and will expect "your silly app" to "perfectly know" what is, for instance, "PST timezone". I'd throw them a dialog requesting clarification if they mean - Pacific Standard Time, UTC−8:00 - Pakistan Standard Time, UTC+5:00 - Philippine Standard Time, UTC+8:00
Maybe with a "By PST I always mean this one" checkbox.
If you try to guess, you will sometimes "guess wrong", and a smart program taking bad decisions is worse than a dumb program you need to guide.
Also, in the example above you will discover that English is official language in the three countries... :-)
In the US, at least, people have a habit of referring to "PST" as meaning the time on or near the pacific coast whether or not daylight savings is in effect. Mostly it's unambiguous but occasionally it's confusing. Sometimes the timezones are referred to as "PT" (Pacific Time), "ET" (Eastern Time) and so on. Allowing people to choose timezones by their abbreviation is always going to be a minefield. jch
If I recall, correctly, PST/PDT is Pacific Standard Time, and Pacific Daylight Time in the US. Dafydd Dafydd Rhys-Jones | Platform Test Engineer F5 Networks www.f5.com Our Kung fu is Stronger P 206.272. 5555 D 206.272.6280 F 206.272.5556 M 206.291.0706 -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of John Haxby Sent: Tuesday, June 05, 2012 2:12 AM To: Ángel González Cc: tz@iana.org Subject: Re: [tz] tz abbreviations / zdump for programmers On 04/06/12 21:45, Ángel González wrote:
On 04/06/12 17:02, Boruch Baum wrote:
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). I would ask the user.
Yes, the users are stubborn and will expect "your silly app" to "perfectly know" what is, for instance, "PST timezone". I'd throw them a dialog requesting clarification if they mean - Pacific Standard Time, UTC−8:00 - Pakistan Standard Time, UTC+5:00 - Philippine Standard Time, UTC+8:00
Maybe with a "By PST I always mean this one" checkbox.
If you try to guess, you will sometimes "guess wrong", and a smart program taking bad decisions is worse than a dumb program you need to guide.
Also, in the example above you will discover that English is official language in the three countries... :-)
In the US, at least, people have a habit of referring to "PST" as meaning the time on or near the pacific coast whether or not daylight savings is in effect. Mostly it's unambiguous but occasionally it's confusing. Sometimes the timezones are referred to as "PT" (Pacific Time), "ET" (Eastern Time) and so on. Allowing people to choose timezones by their abbreviation is always going to be a minefield. jch
On 5 Jun 2012, at 18:46, Dafydd Rhys-Jones wrote:
If I recall, correctly, PST/PDT is Pacific Standard Time, and Pacific Daylight Time in the US.
You are, of course, correct. It was my misfortune to work with someone who insisted that a meeting was going to be at Pacific Standard Time, that meeting was arranged a few *before* daylight savings began in Spring for a date a few days after. We checked, yes, she did mean PST and she got quite heated about it. We ignored that and decided to schedule the meeting for PDT anyway as the UK clocks hadn't changed so it made a difference to us. It's not just that one person, I've since come across others who think that it's PST all year round, sometimes with daylight savings in force, sometimes not. It's not that long ago that someone thought we in the UK were on GMT all year round. US TV often advertises programs starting at some time ET (eastern), MT (mountain) or PT (pacific) without any reference to daylight savings. This actually makes sense but may contribute to confusion. Asking people to provide a timezone for the purposes of, for example, scheduling meetings, is a minefield. Especially around the vernal and autumnal time changes. Subscribers to this list are in a minority in understanding timezones! jch
The ambiguity over what is standard time in the U.S. is not helped by the actual law, which uses the word 'standard time' without capital letters to refer to whatever time is the legal time in a zone. I other words, if I understand this correctly, the standard time on the west coast right now is Pacific Daylight Time, and the standard time during December, e.g., will be Pacific Standard Time. See the actual regulation at "http://tycho.usno.navy.mil/260.html", sections 260 through 265. So when a person says that something will occur at 7:30 pm xx standard time, they may mean according to the wall clock at that time. Dave C. On 05-Jun-2012, John Haxby wrote:
On 5 Jun 2012, at 18:46, Dafydd Rhys-Jones wrote:
If I recall, correctly, PST/PDT is Pacific Standard Time, and Pacific Daylight Time in the US.
You are, of course, correct. It was my misfortune to work with someone who insisted that a meeting was going to be at Pacific Standard Time, that meeting was arranged a few *before* daylight savings began in Spring for a date a few days after. We checked, yes, she did mean PST and she got quite heated about it. We ignored that and decided to schedule the meeting for PDT anyway as the UK clocks hadn't changed so it made a difference to us.
It's not just that one person, I've since come across others who think that it's PST all year round, sometimes with daylight savings in force, sometimes not. It's not that long ago that someone thought we in the UK were on GMT all year round. US TV often advertises programs starting at some time ET (eastern), MT (mountain) or PT (pacific) without any reference to daylight savings. This actually makes sense but may contribute to confusion.
Asking people to provide a timezone for the purposes of, for example, scheduling meetings, is a minefield. Especially around the vernal and autumnal time changes. Subscribers to this list are in a minority in understanding timezones!
jch
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5046 - Release Date: 06/05/12
John Haxby said:
It's not that long ago that someone thought we in the UK were on GMT all year round.
Microsoft still do (or at least seem to think that "GMT" means "UK legal time"). -- 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
On 2012-06-06 11:52, Clive D.W. Feather wrote:
John Haxby said:
It's not that long ago that someone thought we in the UK were on GMT all year round.
Microsoft still do (or at least seem to think that "GMT" means "UK legal time").
It seems fairly hard for the user to tell if their Windows computer is currently showing daylight savings time or not! E.g. on my XP virtual machine, the 'Date and Time Properties' dialog claims the current time zone is "GMT Standard Time" on the 'Date & Time' tab, displayed as "(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London" in the drop down list on the 'Time Zone' tab. In the registry, there is a sub-key called 'GMT Standard Time' that contains a registry value 'Dlt' set to "GMT Daylight Time". I don't know if that string registry value ever gets displayed by the system in normal operation. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 2012-06-06 12:46, Ian Abbott wrote:
On 2012-06-06 11:52, Clive D.W. Feather wrote:
John Haxby said:
It's not that long ago that someone thought we in the UK were on GMT all year round.
Microsoft still do (or at least seem to think that "GMT" means "UK legal time"). [snip] In the registry, there is a sub-key called 'GMT Standard Time' that contains a registry value 'Dlt' set to "GMT Daylight Time". I don't know if that string registry value ever gets displayed by the system in normal operation.
It's been pointed out to me that XP systems set to this zone will show "GMT Daylight Time" and in fact I have XP systems showing that. The XP system that showed "GMT Standard Time" was only recently installed and hasn't seen any DST transitions yet, although that is no excuse for showing the wrong DST information. It might have been something to do installing it in a virtual machine running under Linux, so if that's the reason for it showing the wrong DST information, I apologize to Microsoft. (I don't have the time or inclination to install XP on real hardware at the moment to check.) I also noticed that Windows 7 displays the same zone name to the user as "(UTC) Dublin, Edinburgh, Lisbon, London" with a note underneath to say that Daylight Savings is in effect. Perhaps the use of "UTC" to mean "legal time in Eire, Scotland, Portugal and England" is even more confusing than "GMT"! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Ian Abbott wrote:
I also noticed that Windows 7 displays the same zone name to the user as "(UTC) Dublin, Edinburgh, Lisbon, London"
So they've moved on from "GMT" to "UTC". The parenthesised part previously referred, and presumably still refers, to the zone's "standard" (non-DST) offset from UT. So for London it's "GMT" and for Paris it's "GMT+1", for example, regardless of whether DST is in effect. It seems extremely unlikely that they're making any meaningful distinction between GMT and UTC (i.e., the sub-second difference between flavours of UT). Of course, hardly anyone else makes that distinction in a timezone context anyway.
Perhaps the use of "UTC" to mean "legal time in Eire, Scotland, Portugal and England" is even more confusing than "GMT"!
Are they doing that? The existing misuse of "GMT" is in the strings "GMT Standard Time" and "GMT Daylight Time", which name the two states of the timezone. Have those changed to "UTC Standard Time" and "UTC Daylight Time"? The "(GMT) ... London", as I noted above, is describing one of the offsets, and neither that nor "(UTC) ... London" is incorrect for that purpose. Albeit a bit misleading: its purpose would be clearer if it had an explicit "+0". -zefram
On 2012-06-06 17:00, Zefram wrote:
Ian Abbott wrote:
I also noticed that Windows 7 displays the same zone name to the user as "(UTC) Dublin, Edinburgh, Lisbon, London"
So they've moved on from "GMT" to "UTC". The parenthesised part previously referred, and presumably still refers, to the zone's "standard" (non-DST) offset from UT. So for London it's "GMT" and for Paris it's "GMT+1", for example, regardless of whether DST is in effect.
Yes, you're correct. My excuse for not noticing is that I live in the UK. ;-)
It seems extremely unlikely that they're making any meaningful distinction between GMT and UTC (i.e., the sub-second difference between flavours of UT). Of course, hardly anyone else makes that distinction in a timezone context anyway.
Perhaps the use of "UTC" to mean "legal time in Eire, Scotland, Portugal and England" is even more confusing than "GMT"!
Are they doing that? The existing misuse of "GMT" is in the strings "GMT Standard Time" and "GMT Daylight Time", which name the two states of the timezone. Have those changed to "UTC Standard Time" and "UTC Daylight Time"?
No, they're still "GMT Standard Time" and "GMT Daylight Time" in the registry 'Std' and 'Dlt' registry values in the timezone registry key 'GMT Standard Time'. (I think the 'Std' and 'Dlt' registry values get used by the strftime's "%Z" format specifier in the Microsoft CRT and its char *_tzname[2] array if the TZ environment variable is unset, although the registry also contains references to items within a resource DLL ("tzrez.dll"), so maybe the strings in the resource DLL get used sometimes. I don't know the order of preference for the different sources.)
The "(GMT) ... London", as I noted above, is describing one of the offsets, and neither that nor "(UTC) ... London" is incorrect for that purpose. Albeit a bit misleading: its purpose would be clearer if it had an explicit "+0".
All the zones at UTC+0 (or at least the three I looked at casually) appear to have displayed names beginning "(UTC)" instead of "(UTC+00:00)" or "(UTC-00:00)". The same appears to be true for XP except for the UTC/GMT substitution in the displayed names. Windows 7 also has a zone called "UTC" that XP lacks. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Ian Abbott wrote:
"(UTC+00:00)" or "(UTC-00:00)"
Speaking of this, did anyone else notice that (a) ISO 8601 requires a zero offset to be denoted with a "+" sign, forbidding "-00" (ISO 8601:2000 clause 5.1.1 or ISO 8601:2004 clause 3.4.2), and (b) RFC 3339 is supposedly a profile of ISO 8601, and (c) RFC 3339 *does* allow "-00", denoting the same offset as "+00", but connoting that it's not specifying a preferred offset? I got suspicious about this some months ago, but only got around to confirming the conflict last week. I'm a bit ashamed that I didn't notice it in time to influence RFC 3339, but in my defence I wasn't actually in the WG. This is, of course, only tangentially relevant to the TZ database. The most closely related situations that we're directly concerned with are offsets in zic source files and in the Etc/GMT[-+]* zone names, neither of which makes any claim to conform to either of these contradictory standards. -zefram
Zefram <zefram@fysh.org> writes:
Speaking of this, did anyone else notice that
(a) ISO 8601 requires a zero offset to be denoted with a "+" sign, forbidding "-00" (ISO 8601:2000 clause 5.1.1 or ISO 8601:2004 clause 3.4.2), and
(b) RFC 3339 is supposedly a profile of ISO 8601, and
(c) RFC 3339 *does* allow "-00", denoting the same offset as "+00", but connoting that it's not specifying a preferred offset?
I got suspicious about this some months ago, but only got around to confirming the conflict last week. I'm a bit ashamed that I didn't notice it in time to influence RFC 3339, but in my defence I wasn't actually in the WG.
This convention didn't originate from RFC 3339. It comes from RFC 2822 (published April 2001 but in progress long, long before that): The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone. I was a member of the RFC 2822 working group towards the end of the process, but I think this was already well-settled before then. It is, however, new in RFC 2822 compared to RFC 822. Appendix B of RFC 2822 lists it as a change from earlier standards: 7. Specifically allow and give meaning to "-0000" time zone. RFC 822 (August 1982) allowed both -0000 and +0000 with the same meaning: zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM) (Note the notorious error in the definition of the military zones.) RFC 822 says that this form comes from ANSI X3.51-1975: The other remaining two forms are taken from ANSI standard X3.51-1975. One allows explicit indication of the amount of offset from UT; the other uses common 3-character strings for indicating time zones in North America. This text is unchanged from RFC 733 (November 1977). A quick Google search doesn't immediately reveal an online free copy of ANSI X3.51-1975. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Wed, 06 Jun 2012, Russ Allbery wrote:
Zefram <zefram@fysh.org> writes:
Speaking of this, did anyone else notice that
(a) ISO 8601 requires a zero offset to be denoted with a "+" sign, forbidding "-00" (ISO 8601:2000 clause 5.1.1 or ISO 8601:2004 clause 3.4.2), and
Since ISO 8601 is not freely available (or at least was not freely available years ago), and the freely-available summaries did not mention this, no, I had not noticed.
(b) RFC 3339 is supposedly a profile of ISO 8601, and
(c) RFC 3339 *does* allow "-00", denoting the same offset as "+00", but connoting that it's not specifying a preferred offset?
This convention didn't originate from RFC 3339. It comes from RFC 2822 (published April 2001 but in progress long, long before that):
The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone.
I think that RFC 2822 got that from a convention that was first advocated by Dan Bernstein in 1996. The oldest references that I was easily able to find are from March 1996: A message from djb@koobera.math.uic.edu (D. J. Bernstein) to the DRUMS mailing list (which was working on what became RFC 2822): <http://notabug.com/2002/drums-archive/1320> The time shown MUST be the sender's local time. Exception: the zone -0000 indicates that the local time is unavailable or meaningless, and that the time shown is the actual time. (In contrast, the zone +0000 indicates that the time shown is both local time and actual time.) and an entry in the qmail CHANGES file <http://www.qmail.org/netqmail/CHANGES>: 19960325 change: time zone is now -0000 instead of +0000. encouraging DRUMS to use this as an i-don't-know-the-local-time indicator. --apb (Alan Barrett)
Zefram said:
Are they doing that? The existing misuse of "GMT" is in the strings "GMT Standard Time" and "GMT Daylight Time", which name the two states of the timezone.
But these are meaningless terms. GMT is (to the 1s precision level) the solar mean time at Greenwich. The civil time in the summer is called "British Summer Time" ("BST"); GMT remains unaltered during the summer. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you all for your feedback. I'll continue my work, and report back when I have a deliverable for zdump() etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPz3c4AAoJEDvrUfDmCx9LgB0QAIMXK2Xk3z5/lYdZvC1lgy2c xgH7cckctHlrAc7XPPYmCqPKCdwAP7tbCLNJKx1A75W5L7m2TioUzsyP32tvZe6E s25ilVuYrgqRCAVGzAKS8pKLiE/+wjJCC6Z21JHNiikVOznaFxkYZkyFaEb72f1S tUtFvTWmaswXpMGpWVPwiPsBJwrNvtOjzx2z0FvHNcCVSJkuB+3JkDzZwDgouDMy uCHe7KvNZs0eBJ4OOmiz1N7xEkjQF+fZmwAMM62qJjORI1+xHnwuOacytzoe8nzD jFndQS+5/rYyR8ueH4GHfPWq8SsmMNgoQrEP3CbiF9SEq25l3r8Q9o/+ywh34ay6 Y6ExU49Z1IXYPKnxrupcQdJx/HT3dXa9F+MbZ75uJ7sVj04dPR6NhOhv5fHt0918 m0HgXy3MfruuK1N3rDz+mAK0JjDXzsIn26L7fA/gheN4K3MmKi6ewE5bTBLRhQoy Y6PTxV08pBE/3BJ0PiwMZAm9n1JbZdeoYo88LABASEposbLO8wVKlg+7glhyJlUJ Jl77FBLQwviEdbTholpFvMD26zCSee2NyMzgQN4VAS+M6cKT2M0nvD2YLhiAEBz5 EyUlQc4GkbSn9fvJqEhkZ+aJKqvZWdpijGTBMJC0xy1SBLU3V/yo5KiOvNT6JdMM WtQZAwGthlzSMF9z+m2F =T5h/ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/06/2012 11:28 AM, Boruch Baum wrote:
Thank you all for your feedback.
I'll continue my work, and report back when I have a deliverable for zdump() etc.
https://github.com/Boruch-Baum/zdump-3- I've pushed a first commit to github with a C function to retrieve data from zoneinfo files. The repository includes a program to test the function (zdtest), a program to view a zoneinfo file's contents in order to verify the output (tzif-display), a man page (zdump.3) and two tangential bash scripts to illustrate the lack of localization of timezone abbreviations. In order to complete testing the function, I'm looking for zoneinfo files that use the 'J' ruleset (as opposed to the 'M' ruleset). Does anyone know of a zoneinfo file that uses the 'J' ruleset? Does anyone on the list have a package of 'theoretical' zoneinfo files that I could use for testing? All are welcome to try out the code, and please report any bugs, unexpected behaviours, or missing features. Also, any other feedback is welcome. Bugs and "issues" can be reported either via github (more convenient for me) or directly by e-mail to me (if github is not convenient for you). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP4NZoAAoJEDvrUfDmCx9LS8MQAJAX97d0M7BAKuuJ/XKIXW+8 QfJxgn7/btRNZBhB3Ty4gOZI8PSZMyPytVopy0GwZW4vcl917llAgBNSAmCaWUcS 0QqWJ0QYkXe3qAbL47Y8W8fGolrjEVT97aR5DmKVC9sFjmZeFYtWYi6g1PlOsKbw mlA/IWegJUR1Efu8mSY4SteOI+Qz1uuc/n8sBWl9v7qFEGRenDVInGF6VDrbjGK+ okpiQxRvKADrRhRXOBa511i3U+QZkFCO29B/lE7SuOisXfOzfr79mJjtfhQryszp 3T3AuKqDNG5p/gpYHzONkzq5tT/ADihv0MK8IFo1K8qSNQeKHAh42l6S5Pk0YpK9 ApMVrndh7H3lCj7wM/QjDDIWGwD7RgRrmKOV4AZxcuZBkeMrVfYNzjp4o5lYp1Gk SkiTW8ZbZmESYyDmHt3sddK8TgOf4UUT138NmaB7D+Yv/Dut/mDoJTxR4RfT0897 yeMsfLIpvLEYOVBKte1DuO+fMV8YVcTTgwE9Av0dmWR5WSFKMAHTEf/6G/TyBgvi tu6vH2kum5+5KQu0QHMEI9k7gG7CjBxkXv+uNUYRTAwYv8h9wFbxzolN28+wlKAJ gG11YG125E0Tfxea1S1GAyDdzPMRWL7m5oZlm7e4MYn/fUJy0hPL29r/+NYbPd3R 6nUFPKjw/7CObxN5n8Dv =1ONi -----END PGP SIGNATURE-----
On 06/06/2012 11:28 AM, Boruch Baum wrote:
Thank you all for your feedback.
I'll continue my work, and report back when I have a deliverable for zdump() etc.
https://github.com/Boruch-Baum/zdump-3- I've pushed a first commit to github with a C function to retrieve data from zoneinfo files. The repository includes a program to test the function (zdtest), a program to view a zoneinfo file's contents in order to verify the output (tzif-display), a man page (zdump.3) and two tangential bash scripts to illustrate the lack of localization of timezone abbreviations. In order to complete testing the function, I'm looking for zoneinfo files that use the 'J' ruleset (as opposed to the 'M' ruleset). Does anyone know of a zoneinfo file that uses the 'J' ruleset? Does anyone on the list have a package of 'theoretical' zoneinfo files that I could use for testing? All are welcome to try out the code, and please report any bugs, unexpected behaviours, or missing features. Also, any other feedback is welcome. Bugs and "issues" can be reported either via github (more convenient for me) or directly by e-mail to me (if github is not convenient for you).
participants (16)
-
Alan Barrett -
Boruch Baum -
Brian Inglis -
Clive D.W. Feather -
Dafydd Rhys-Jones -
Dave Cantor -
Donald MacQueen -
Ian Abbott -
John Haxby -
Paul Eggert -
Petr Machata -
Russ Allbery -
Steffen Daode Nurpmeso -
Tobias Conradi -
Zefram -
Ángel González