Thank you for the input! Maybe I should clarify the file. This is an attempt to allow users or peoples access to their times zones. A date string, publication, scanned document, broadcast, etc. can contain the time zone. The tz database even includes these time zones. Some functions even require them to operate. Take the "conceptional problem" example. BRT/BRST are the abbreviations used for the Brazilia Time zone. The ":America/Sao_Paulo" file/location is defined as using the Brazilia Time rule "Brazil". Since this location follows Brazilia Time, it is given the abbreviation for that zone. It is not given a synonym for an offset from UTC. An example to clarify could be the recent offset change of Moscow Time zone from an offset of 3 to that of 4. MSK is the abbreviation for the regional time zone using the standard time definition of that zone. The ":Europe/Moscow" file assigns the offset used for that zone. The Moscow file can now safely be used to represent the "Moskva" rule that is the regional time zone, rather than creating a new zone. Since it is the only location that uses that time zone, one can assign ":Europe/Moscow" file as a link. The GMT example is an oddity case. GMT can stand both for a time, :Etc/GMT which I assume is the observatory location, and the English Isles regional time zone. I am also guessing that that was one of the reasons for UTC, so that an offset of 0 from the observatory would be taken as the offset rather the the time zone the English use. I also only compiled the times, as stated in the file, from 1970 to present. It is known that abbreviations are not unique. However, the list of conflicting zones, see near the end of file, is really small. Especially when Australia is assigned the local, state, country definitions and Indonesia. I will look farther into the assignment to see if any additional zones need creation. As it is clear that a present location might not actually be assigned to a time zone. I did not try to resolve conflicts, just link to the base location file that defined the actual time zone for a region. I did try to make sure to avoid not linking a file that didn't represent the regional time zone, but best to be safe. Thanks again, was helpful! Steve
I just want to make sure that people realize that the tz abbrevations are at most useful as internal identifiers. Most of them are not recognizable by end users at all, and are not appropriate for display or choice by end users. Mark *— Il meglio è l’inimico del bene —* * * * [https://plus.google.com/114199149796022210033] * On Wed, Dec 7, 2011 at 11:03, Steven Abner <pheonix@zoomtown.com> wrote:
Thank you for the input! Maybe I should clarify the file. This is an attempt to allow users or peoples access to their times zones. A date string, publication, scanned document, broadcast, etc. can contain the time zone. The tz database even includes these time zones. Some functions even require them to operate. Take the "conceptional problem" example. BRT/BRST are the abbreviations used for the Brazilia Time zone. The ":America/Sao_Paulo" file/location is defined as using the Brazilia Time rule "Brazil". Since this location follows Brazilia Time, it is given the abbreviation for that zone. It is not given a synonym for an offset from UTC. An example to clarify could be the recent offset change of Moscow Time zone from an offset of 3 to that of 4. MSK is the abbreviation for the regional time zone using the standard time definition of that zone. The ":Europe/Moscow" file assigns the offset used for that zone. The Moscow file can now safely be used to represent the "Moskva" rule that is the regional time zone, rather than creating a new zone. Since it is the only location that uses that time zone, one can assign ":Europe/Moscow" file as a link. The GMT example is an oddity case. GMT can stand both for a time, :Etc/GMT which I assume is the observatory location, and the English Isles regional time zone. I am also guessing that that was one of the reasons for UTC, so that an offset of 0 from the observatory would be taken as the offset rather the the time zone the English use. I also only compiled the times, as stated in the file, from 1970 to present. It is known that abbreviations are not unique. However, the list of conflicting zones, see near the end of file, is really small. Especially when Australia is assigned the local, state, country definitions and Indonesia. I will look farther into the assignment to see if any additional zones need creation. As it is clear that a present location might not actually be assigned to a time zone. I did not try to resolve conflicts, just link to the base location file that defined the actual time zone for a region. I did try to make sure to avoid not linking a file that didn't represent the regional time zone, but best to be safe.
Thanks again, was helpful! Steve
Right. I use the long name exclusively. From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Mark Davis ? Sent: Wednesday, December 07, 2011 2:14 PM To: Steven Abner Cc: tz@iana.org Subject: Re: [tz] User time zones I just want to make sure that people realize that the tz abbrevations are at most useful as internal identifiers. Most of them are not recognizable by end users at all, and are not appropriate for display or choice by end users. Mark — Il meglio è l’inimico del bene — [https://plus.google.com/114199149796022210033] On Wed, Dec 7, 2011 at 11:03, Steven Abner <pheonix@zoomtown.com> wrote: Thank you for the input! Maybe I should clarify the file. This is an attempt to allow users or peoples access to their times zones. A date string, publication, scanned document, broadcast, etc. can contain the time zone. The tz database even includes these time zones. Some functions even require them to operate. Take the "conceptional problem" example. BRT/BRST are the abbreviations used for the Brazilia Time zone. The ":America/Sao_Paulo" file/location is defined as using the Brazilia Time rule "Brazil". Since this location follows Brazilia Time, it is given the abbreviation for that zone. It is not given a synonym for an offset from UTC. An example to clarify could be the recent offset change of Moscow Time zone from an offset of 3 to that of 4. MSK is the abbreviation for the regional time zone using the standard time definition of that zone. The ":Europe/Moscow" file assigns the offset used for that zone. The Moscow file can now safely be used to represent the "Moskva" rule that is the regional time zone, rather than creating a new zone. Since it is the only location that uses that time zone, one can assign ":Europe/Moscow" file as a link. The GMT example is an oddity case. GMT can stand both for a time, :Etc/GMT which I assume is the observatory location, and the English Isles regional time zone. I am also guessing that that was one of the reasons for UTC, so that an offset of 0 from the observatory would be taken as the offset rather the the time zone the English use. I also only compiled the times, as stated in the file, from 1970 to present. It is known that abbreviations are not unique. However, the list of conflicting zones, see near the end of file, is really small. Especially when Australia is assigned the local, state, country definitions and Indonesia. I will look farther into the assignment to see if any additional zones need creation. As it is clear that a present location might not actually be assigned to a time zone. I did not try to resolve conflicts, just link to the base location file that defined the actual time zone for a region. I did try to make sure to avoid not linking a file that didn't represent the regional time zone, but best to be safe. Thanks again, was helpful! Steve
On Dec 7, 2011, at 11:03 AM, Steven Abner wrote:
Maybe I should clarify the file. This is an attempt to allow users or peoples access to their times zones.
What precisely do you mean by a "time zone" in this context? And how does it differ from the time zones that individual files in the Olson database handle? (They're obviously not the same, if the existing Olson database doesn't "allow users or peoples access to their time zones".)
Steven Abner wrote:
The GMT example is an oddity case. GMT can stand both for a time, :Etc/GMT which I assume is the observatory location, and the English Isles regional time zone.
No, it can't. In the British Isles, "GMT" unambiguously refers to UT+0h, never to regional civil time. Likewise, "BST" unambigously refers to UT+1h, never to regional civil time. There is no official name for the regional civil time, but "London time" is the most common term I encounter. London time switches between GMT (UT+0h) and BST (UT+1h) on an annual schedule. Where confusion between the two offsets is possible, we disambiguate by explicitly stating "GMT" or "BST". Most obviously, when London time switches from BST to GMT, as it recently did on 2011-10-30: London time was 01:30 twice in one day, the first time being 01:30 BST and the second (an hour later) being 01:30 GMT. This is not an unusual arrangement for timezone abbreviations, not in any way specific to GMT. The same applies with "EST" and "EDT" in the US, for example. Indeed, this is the point of abbreviations varying according to DST status. Perhaps you've been led astray by Microsoft's timezone database, which incorrectly uses "GMT" as the name for the civil timezone applying in London. More generally, MS's database doesn't distinguish properly between non-DST offset description and zone description.
I am also guessing that that was one of the reasons for UTC, so that an offset of 0 from the observatory would be taken as the offset rather the the time zone the English use.
No. The term "Universal Time" (UT) was promulgated due to an ambiguity in the definition of "GMT", but not the one you imagine (which never existed). The real ambiguity was about whether the hours of the day should be counted from midnight or from noon. Older astronomical practice was to count hours (on any meridian) from noon, and so in the 19th century, in technical contexts, "GMT" mainly meant Greenwich (observatory) time counted from noon, which we would now call UT-12h. Civil practice was to count hours from midnight, so "GMT" had different meanings depending on context. The 1884 meridian conference agreed on the Greenwich meridian as the international prime meridian, and agreed that the universal day should be counted from midnight. The term "Universal Time" was used by then to unambiguously refer to Greenwich time counted from midnight. The British astronomical almanac switched meanings of "GMT" in 1925. Previously they'd used the astronomical convention, but from 1925 they counted hours from midnight while continuing to label the time coordinate as "GMT". So "GMT" became de facto ambiguous even in technical contexts at that point. In 1928 the International Astronomical Union recommended using the term "UT" (with its current meaning) instead of "GMT" (with either meaning), to avoid the ambiguity. Note no "C" on "UT": that didn't exist until the 1960s. Nowadays, of course, no one counts hours from noon. Outside a historical context, "GMT" unambiguously refers to the same thing as "UT". Unless you get into sub-second effects, but that's out of the scope of this discussion. Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it. The lookup should be a separate process, and should have explicit handling for abbreviations used by more than one zone. The abbreviations just don't behave like a namespace for these zones, in addition to them actually naming something other than the geographical zone. -zefram
On Wed 2011-12-07T20:37:24 +0000, Zefram hath writ:
Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it. The lookup should be a separate process, and should have explicit handling for abbreviations used by more than one zone. The abbreviations just don't behave like a namespace for these zones, in addition to them actually naming something other than the geographical zone.
If I am not mistaken this is one of the issues under consideration by the Timezone Technical Committee as they work out registry issues and server protocols. http://calconnect.org/tc-timezone.shtml -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Wed 2011-12-07T20:37:24 +0000, Zefram hath writ:
Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it. The lookup should be a separate process, and should have explicit handling for abbreviations used by more than one zone. The abbreviations just don't behave like a namespace for these zones, in addition to them actually naming something other than the geographical zone.
If I am not mistaken this is one of the issues under consideration by the Timezone Technical Committee as they work out registry issues and server protocols. http://calconnect.org/tc-timezone.shtml to which I do reply: If I may suggest an approach, prior to the creation of a definitive solution, it would be to iterate through the various time zones, for each one finding the abbreviations that it can have, and thus building a lookup table from abbreviation to zone. (I imagine a key-value structure where the abbreviation is the key and either an array or a delimited list of zone names is the value, but it really depends on the language you're writing in.) Special-case handling is recommended for the abbreviation LMT, as almost every zone can have that abbreviation. Thus, for example, an input of CST would get America/Chicago, America/Winnipeg, America/Regina, Australia/Adelaide, Australia/Darwin, various minor areas in the vicinity of those, and maybe also Europe/Prague and Europe/Bratislava if "CST" was used there as the placeholder for Czechoslovakia Time (don't have that file in front of me). You would then present those to the user in whatever form you deemed appropriate.
On Dec 7, 2011, at 3:37 PM, Zefram wrote:
No, it can't. In the British Isles, "GMT" unambiguously refers to UT+0h, never to regional civil time. Likewise, "BST" unambigously refers to UT+1h, never to regional civil time.
Thank you! I believe a change is in order. I did not know. So Etc/GMT to Abbr/GMT and A link for BST to a different zone?.
Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it.
I only know that functions are required to handle. And there has been a good reason why no end user currently does use it. Do you know what its like to scan every file to find one zone? much less create a look-up table just so an end user could use the API that says it is suppose to work? This file is my look up so POSIX functions can work, even if its the best guess for now. This has been a great discussion. I hope you or the organization can use the file, if not just for information, or maybe it will generate a final solution. Even if it does mean some sort of name change, like a letter/number suffix? Steve
On Dec 7, 2011, at 1:40 PM, Steven Abner wrote:
On Dec 7, 2011, at 3:37 PM, Zefram wrote:
Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it.
I only know that functions are required to handle. And there has been a good reason why no end user currently does use it. Do you know what its like to scan every file to find one zone? much less create a look-up table just so an end user could use the API that says it is suppose to work? This file is my look up so POSIX functions can work, even if its the best guess for now.
End users don't use APIs, they use applications that use APIs. Programmers use APIs. A user might want to specify to some application some information to select time zone information of some sort - the question is "what sort" and "what do they mean by that"? For example, does "MST" mean "Mountain Standard Time", regardless of whether daylight savings time is in effect or not, so that it's the same as local time in Arizona, or does it mean "the Mountain time zone", so that, in Arizona, it's Mountain Standard Time all the time and, elsewhere in the Mountain time zone, it's Mountain Standard Time part of the year and Mountain Daylight Time in part of the year? I.e., what are the end users you're thinking of trying to *do*? Do they want to, for example, know "what time is it in the Mountain time zone"? If so, they'd better add "in Arizona" or "not in Arizona" to that question? Or do they want to know "what time would it be now in Mountain Standard time?" (even if, outside of Arizona, daylight savings time is in effect) or "what time it would be in Mountain Daylight time"?
On Dec 7, 2011, at 6:27 PM, Guy Harris wrote:
End users don't use APIs, they use applications that use APIs. Programmers use APIs.
Sorry about lose wording. From http://pubs.opengroup.org/onlinepubs/9699919799/ , "If %Z is being scanned, then getdate() shall initialize the broken-down time to be the current time in the scanned timezone."
From my mail "December 7, 2011 6:27:27 PM EST". From same publication, strftime(), conversion specifier Z, "Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists." The publication does not specify %Z for strptime(), however Lunix "%Z The timezone name." Now strptime() should be able to parse a formatted string, so if strftime() formats a string, it would be "expected" to handle "Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists." I belong to the Eastern time zone, which can be represented be the abbreviations EST/EDT depending on the time of year. And a little history, I was shocked when I first used the database and it incorrectly did my time zone with no dst, I used EST. Of course it worked after remembering that EST5EDT was the way I use to do it on the old 8086/8088 (could of been the 286?) machines. Then I found certain towns had different times, and joined different time zones at certain dates, or elected even not to be a part of the time zone, yet still used the time zones abbreviation. So now after about 30 years ......
From what you wrote, it looks like something I saw from Perl. There you or even somebody's application has the option to query further. Then you can accurately pinpoint an actual town or jurisdiction and use an Olson location. I am not sure of what function Perl would use or your application would use if you wished to translate a server in Japan sending a date string of "Maintenance will begin at 12:00 JST" and desired to display it in a local time string. From all my work with the database there is no JST time zone even though the Olson files of :Japan, :Asia/Tokyo state that those locales use the Japan time zone which only uses JST abbreviation representation for Japan Standard Time zone with a UTC offset of +9. How would one even start querying a user. Would you scan all the files? or search the internet of how to interpret JST? Would you just use each file that started with "J" and ask "do you mean Jakarta Standard Time?" or open each file looking for an abbreviation? What if your application shouldn't interact to convert to local time display?
I have no idea how people want to design an application or want to use the database for there gain. I do know what is well published and what research I have found. Several websites even publish the abbreviations, some dictionaries have entries. Why shouldn't a function that deals with time not be allowed to use a time zone as input, when it is well understood what the abbreviation stands for? And why shouldn't a group of people that deal with time zone information not be the fore runners in setting up a means of allowing programmers to present this to the public. I am by no means trying to dictate how a person should use the database nor trying to limit a user's means of displaying time. I had a problem using the database, found a solution, and opted to share what I discovered. I had more questions, and this seem to sate my needs. And fortunately I have received a lot of great input and questions to help me sure up what I need the database for. Hopefully you all might benefit as well? Sorry if not the best with words, Steve
Steven Abner <pheonix@zoomtown.com> writes:
I am not sure of what function Perl would use or your application would use if you wished to translate a server in Japan sending a date string of "Maintenance will begin at 12:00 JST" and desired to display it in a local time string.
One of the reasons why you're finding this example challenging is that such a time specification is fundamentally broken. "12:00 JST" is not a well-formed and unambiguous specification of a time. This becomes even more obvious if the example were "12:00 EST", which could refer to a time in either the east coast of the United States or in Australia (to tie this back to another perennial discussion of time zone abbreviations). Thinking that time zone abbreviations are meaningful ways of representing time is partly a US-centric (and to a lesser extent Western-European-centric) view of time. Many of the time zones in the world have no official abbreviations. Many others have ambiguous abbreviations. This is why ISO 8601 does not permit times to be specified using an alphanumeric time zone representation. Instead, it requires that time zones be specified with the -0500 or -0800 or +0100 offset, which is unambiguous and does not present these problems. It's also why Internet standards such as for the Date header field of mail messages no longer allow time zone abbreviations as the canonical method to indicate the time zone of a time.
Why shouldn't a function that deals with time not be allowed to use a time zone as input, when it is well understood what the abbreviation stands for?
Because it's not well-understood what the abbreviation stands for. That's the whole point. If you have to accept abbreviations because you're attempting to adjust for broken input, then you have to guess. I've written code to do that to deal with obsolete-format Usenet messages; I'm sure many others here have as well for other applications. You build a table of time zone abbreviations and their corresponding offsets and hope that's what the abbreviation was intended to mean, and you do something for the cases where you can't guess (usually fall back on UTC). But you shouldn't lose track of the fact that you're guessing. You're taking a stab in the dark at interpreting ambiguous and malformed input, and some percentage of the time you're going to be wrong. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
It sounds as if the only problem you're trying to solve is that of converting a date and time, plus a time-zone-and-DST abbreviation, into a UTC value, so that it can be, in turn, converted to local time in some other location. The *best* way to solve that problem is, if possible, to have the text strings in question *not* use time-zone-and-DST abbreviations, but instead to use UTC or to use, as Russ Allbery said in his message, an explicit numerical offset-from-UTC value. I.e., the best way to solve that problem is not to have it in the first place. If, however, you're stuck with having to parse text that uses time-zone-and-DST abbreviations - i.e., you can't just avoid the problem - then, as long as the ambiguous cases can be eliminated (again, see past discussions of Australian time zone) or ignored, and as long as the abbreviations you specify in the database are used for all the strings you parse (i.e., no date/time/zone string uses an abbreviation *not* in the database), then your proposal to add special Olson database entries that have names that include the abbreviation and have a fixed offset-from-UTC would be one solution; another would be to maintain, as Russ suggested, a separate abbreviation-and-offset-from-UTC database. Note that a mapping from abbreviations to offset-from-UTC is *NOT* necessary to make strptime() work, as strptime() is *not* required by the Single UNIX Specification to do anything useful with a time zone abbreviation in the string being parse - and, in fact, the Single UNIX Specification would have to be changed to require that a "struct tm" have a place to *put* the time-zone-and-DST abbreviation if it were to specify that something be done with %Z in strptime(). As for getdate(), well, they may say If %Z is being scanned, then getdate() shall initialize the broken-down time to be the current time in the scanned timezone. but what does that mean it should do with, for example, %Z matching "EST" if, when the program is run, the part of the Eastern time zone that has daylight savings time is in daylight savings time? Is "the current time in the scanned timezone" the current time in the Eastern time zone in daylight savings time (that being what the clock on the wall says) or in standard time (because it's "EST")? if the format string that matches it is, for example, "%Y-%m-%d %H:%M:%S %Z"? (Note that I'm deliberately trying to avoid using the phrase "time zone". The Olson database doesn't have entries for time zones; most of its entries are entries for regions on the Earth's surface. A given region can have an offset-from-UTC that varies in fairly complicated fashions, and can even move from one time zone to another, e.g. the America/Indiana/Indianapolis region switched from the Central time zone to the Eastern time zone on April 24, 1955 - *and*, at the same time, it stopped having daylight savings time. It then started having DST again in 1969, stopped having it in 1971, and started again in 2006. That's why I'm saying "Olson database entries". An abbreviation such as "EST" or "EDT" specifies both a time zone and a standard time vs. daylight savings time indication, so it doesn't correspond to just a time zone. That's why I'm saying "time-zone-and-DST abbreviation".)
Steven Abner wrote:
I am not sure of what function Perl would use or your application would use if you wished to translate a server in Japan sending a date string of "Maintenance will begin at 12:00 JST" and desired to display it in a local time string.
That sort of thing is properly tackled in the opposite direction. When maintenance will start is a point in time, independent of timezone, and so should be represented in UT or equivalent. Then it can be trivially converted to each user's preferred timezone for display. For example, $ maintdate='2011-12-09 00:00 UT' $ for TZ in America/New_York America/Sao_Paulo Asia/Tokyo; do date -d "$maintdate" +'Maintenance will begin at %H:%M %Z on %A.'; done Maintenance will begin at 19:00 EST on Thursday. Maintenance will begin at 22:00 BRST on Thursday. Maintenance will begin at 09:00 JST on Friday. If you really need to go the other way... well, that's pretty bizarre. You're scraping a human-oriented announcement "Maintenance will begin at 12:00 JST" from someone's server, the format is rigid enough for you to reliably pick out "12:00 JST" as a time indicator, but the application isn't specific enough for you to statically configure that this server uses Tokyo time? I don't believe it as stated. There are more plausible scenarios, though, where you could get "12:00 JST" as a time indicator and have to automatically interpret it. In that case, firstly, you don't want to go to the Asia/Tokyo timezone per se. The job isn't to guess which geographical zone applies, it's to guess what "JST" means. That's not so much of an issue with "JST", but consider "MST": you don't really care where it's coming from America/Denver or America/Phoenix, it could be either and means the same either way. If you get "MST" for a date in July then it's probably America/Phoenix, and you'd go quite wrong if you were to interpret it as America/Denver and use the offset that Denver uses in July. (Denver uses the abbreviation "MDT" in July.) Secondly, you need to accept that you're guessing. There are ambiguities, and if you can't have any user input to disambiguate then you're going to go wrong sometimes.
Would you scan all the files? or search the internet of how to interpret JST?
Once you've got the above issues clear, actually performing the guess is fairly easy. As you point out, it's a bit much to search through every zone file each time, at least if you're doing this regularly, so it's sensible to build an abbreviation-to-whatever index. Generating the index is trivial, by a single pass through every zone file. Depending on application, you might want to limit the indexing to abbreviations used in the last N years (so no "LMT" outlier). Looking up an abbreviation in the index will give you a small list of candidate offsets. If you want to be clever, you could try narrowing down the list further by checking the slightly larger list of candidate geographical timezones, to see whether the abbreviation is meant to be in use at the time of year that the time expression appears to depict.
How would one even start querying a user.
If you've got a user to query, you can do this properly. You usually want to know a user's timezone for output purposes. Usually a geographical civil timezone, and you *do* want to distinguish America/Denver from America/Phoenix. The zone.tab file provides a convenient structure for this, based on contemporary political geography. You end up with a dialogue going something like "what continent are you in?" "Asia" "which of these countries?" "Japan" "right, you'll be wanting Asia/Tokyo". Countries with multiple timezones get an additional question, "is that east or west Uzbekistan?". tzselect.ksh in the tz distribution implements this system in a simple way. Some refinements are possible, such as displaying the current time (and abbreviation) in each candidate zone. If, bizarrely, you've got "JST" from a user, and then want to ask to disambiguate (or confirm) it, that'll be a much shorter line of questioning. Use the index discussed above to get a list of candidate geographical zones, and then show them to the user (possibly using the descriptions from zone.tab, though they don't cover all zones in the database, this isn't what they're for), and ask the user to pick one. Here's a very crude version of this type of search: $ for TZ in $(comm -23 \ =(grep -wl JST /usr/share/zoneinfo/posix/**/*(.) | \ sed 's,.*posix/,,' | sort) \ =(grep '^Link' ~/tmp/tz/* | awk '{print $3}' | sort)); do date +'%a %H:%M %Z%t'$TZ; done Thu 20:31 TLT Asia/Dili Thu 19:31 HKT Asia/Hong_Kong Thu 18:31 WIT Asia/Jakarta Thu 19:31 MYT Asia/Kuala_Lumpur Thu 19:31 MYT Asia/Kuching Thu 19:31 CIT Asia/Makassar Thu 19:31 PHT Asia/Manila Thu 18:31 WIT Asia/Pontianak Thu 18:01 MMT Asia/Rangoon Thu 22:31 SAKT Asia/Sakhalin Thu 19:31 SGT Asia/Singapore Thu 20:31 JST Asia/Tokyo Thu 23:31 NRT Pacific/Nauru Obviously, grep is just turning up every zone that has ever used "JST" at all, possibly with some false positives. You can do better by properly parsing the tzfiles. You can limit to zones that have used the abbreviation recently, and so on.
What if your application shouldn't interact to convert to local time display?
It'll still need some kind of input to determine which timezone to use. A zone abbreviation is a rather unlikely form of such input. If you can't get an explicit zone name input then you'll have to guess to some extent, of course. GeoIP will give you a decent guess. -zefram
What others have said, I would put simply: always transmit and store times in UTC. Only convert to local timezones in user interfaces. Otherwise, you'll lose your mind, fast. Also, force your data sources to use UTC. Otherwise, they'll lose their mind too. -- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
My boss is forcing me to have both UTC and local time in the database. I've pointed out this is a colossal waste of time and space and then said, "Yes, sir.":) -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Jaakko Hyvätti Sent: Thursday, December 08, 2011 7:21 AM To: tz@iana.org Subject: Re: [tz] User time zones What others have said, I would put simply: always transmit and store times in UTC. Only convert to local timezones in user interfaces. Otherwise, you'll lose your mind, fast. Also, force your data sources to use UTC. Otherwise, they'll lose their mind too. -- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
always transmit and store times in UTC.
I don't think this is perfect. The issue is that the conversion between local and UTC involves the tz database (or similar) and that is a moving target. You can very well have tz_local_to_utc (t0, tzid, tzversion1) != tz_local_to_utc (t0, tzid, tzversion2), (after all, we would not need many versions of tz every year if that was not the case) and therefore tz_utc_to_local (tz_local_to_utc (t0, tzid, tzversion1), tzid, tzversion2) != t0. A possible scenario: create an appointment for a time in the future using tzversion1, store the UTC time, and later read the appointment using tzversion2; the time of the appointment may have changed. It is true that in many parts of the world, the likelihood of that scenario is low, but there are others where it's far less uncommon. Also note that the scenario applies equally well to client/server vs. local, one user creating and another reading vs. the same user doing both. Storing both local and UTC may not be the best to fix this, or not quite enough, because it does not tell you which of the two values is the authoritative one. I don't quite see any other solution than storing a time together with the timezone in which it is expressed. That time zone may be UTC. If you make an appointment for a meeting in Moscow, then you really want to store the local time (it does not matter much how that local time relates to UTC, you'd better be there when the local clocks say so); if you make an appointment for a teleconference with participants across the world, then you really want to store the UTC time, and let everyone figure out what it mean (or will mean) for them. That puts a burden on users of choosing the timezone, but fortunately, local time is a good default, and only those who deal with multiple time zones have to choose UTC. There is the subsidiary issue that what people really need is "the timezone of this location", rather than "this tz timezone". The difference shows up in the tz database whenever a new tz timezone is introduced. Fortunately, such changes are much less frequent. Eric.
On Dec 8, 2011, at 10:12 AM, Eric Muller wrote:
I don't quite see any other solution than storing a time together with the timezone in which it is expressed.
Where by "timezone" you presumably mean "reference to an Olson database entry" or, as you use later, "tz timezone". "June 17, 2012, 11:00 in the Mountain time zone" is insufficient information to generate a UTC date - you don't know whether it's in Arizona or not.
There is the subsidiary issue that what people really need is "the timezone of this location", rather than "this tz timezone". The difference shows up in the tz database whenever a new tz timezone is introduced. Fortunately, such changes are much less frequent.
...and solving that problem involves perfectly predicting the future, i.e. it's impossible.
On 8 Dec 2011, at 18:12, Eric Muller wrote:
A possible scenario: create an appointment for a time in the future using tzversion1, store the UTC time, and later read the appointment using tzversion2; the time of the appointment may have changed. It is true that in many parts of the world, the likelihood of that scenario is low, but there are others where it's far less uncommon. Also note that the scenario applies equally well to client/server vs. local, one user creating and another reading vs. the same user doing both.
This is exactly why calendaring applications store the time of the appointment along with its timezone. I have a regular weekly meeting when the clock on the meeting room wall in California says "11am". Depending on the time of year that's either 7pm or 6pm for me in the UK. If California decided to change its timezone (to align with Hawaii perhaps) or abandon DST then that meeting would still be guided by that clock on the meeting room wall and not by the time here in the UK. The only thing that's not tied to a timezone is an anniversary. Easter next year, for countries that care, is on 8th April and runs from midnight to midnight regardless of where you are. This is, of course, what you said! jch
:-) And then my phone notices that I travelled to another timezone and displays my meetings back home next week as 3am and how much does this help me.. but it would be good to display teleconferences this week in my temporary local time now.. and I should have been able to schedule my travel meetings in advance in destination local time. How can a calendar application guess? And if you need to configure it, it is too complicated for 99% of users, including me, I just do not care enough. -- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
On Dec 8, 2011, at 6:39 AM, Zefram wrote:
In that case, firstly, you don't want to go to the Asia/Tokyo timezone per se. The job isn't to guess which geographical zone applies, it's to guess what "JST" means. That's not so much of an issue with "JST", but consider "MST": you don't really care where it's coming from America/Denver or America/Phoenix, it could be either and means the same either way. If you get "MST" for a date in July then it's probably America/Phoenix, and you'd go quite wrong if you were to interpret it as America/Denver and use the offset that Denver uses in July. (Denver uses the abbreviation "MDT" in July.)
In agreement. The file list submitted was not to look up Toyko but to define JST for quick and simple access. And UT could be done and should also be handled, or use of %z where it's an offset. I don't think there is any bug or ever an incorrect use of %z. It is also the right of any programmer or application designer to simply not convert and crash the app if thats what they decide. Not trying to dictate the terms of use of time nor time zone information! For MST, let's first state that yes there are 8 zones that have conflicts. In the case of MST, there is no conflict. If let's say Denver in July did output a timestamp string of 12:00 MST, then it is a sure thing that the computer output the correct conversion to MST, or if it didn't, a sure thing that the use of strftime() and/or mktime() has a bug in that system. Again don't care where it originates, just assume that the computer can output a string for that locale or any locale. By looking up what zone the abbreviation stands for, a conversion to any zone, locale, UTC offset is easily handled. Let's even go one step further, Denver in July output the 12:00 MST, convert it for use in Denver. mktime() is required to handle this and will output 1:00 MDT, if that was the requested format, but regardless of output, the broken-down time structure will contain the wall time information for Denver. Let's try a past event for America/North_Dakota/Beulah, currently in Central. What if the computer output July 4, 8PM 1976 MDT or even July 4, 7PM 1976 MST and we are asked to interpret for anywhere. Really don't care where it came from, just that from the look up MST = -7 and MDT = -6 for the time asked. Very easily retrieved from the Link to MST7MDT. I now can even convert to Mars Time if that was in the database. Even the use of a static locale like Phoenix, if a computer can output the time correctly, conversion using the link to MST7MDT to any other locale or zone can be done. I am still looking for exceptions, outside the 8 zones of conflict. And yes, I could have missed some! Clear example is my incorrect knowledge of GMT. As for an LMT case, sorry I only did 1970 and up, and have no information. The tz database mentions several times that it was more focused in this region of the time line. The file was more concerned with trying to go from present to future events. Some abbreviations are listed in the look up even though not in use today, and they had no conflict, if memory serves. Thanks loads for all responses! Steve
On 08/12/11 14:39, Steven Abner wrote:
For MST, let's first state that yes there are 8 zones that have conflicts. In the case of MST, there is no conflict. If let's say Denver in July did output a timestamp string of 12:00 MST, then it is a sure thing that the computer output the correct conversion to MST, or if it didn't, a sure thing that the use of strftime() and/or mktime() has a bug in that system
There's an additional problem. People mis-write times. I've missed meeting because the meeting organiser said it was "9am PST" but since that was shortly after the clocks changed in spring I was out by an hour. Well, I would have been except that I asked for clarification and told it was "standard time" which the meeting organiser took to be PST in winter and PDT in summer. Some years later I had the same problem with another person who assumed that GMT simply meant UK local time which, of course, it does not. Not only do you have to guess at what the abbreviation might mean, you also have to guess at what was in the mind of the person writing the time, regardless of the locale they are from and the locale whose time they are writing down. It's hard enough for humans to get this right with all the context that they have, it's impossible for software to get it right. jch
Steven Abner wrote:
even go one step further, Denver in July output the 12:00 MST, convert it for use in Denver. mktime() is required to handle this and will output 1:00 MDT,
You seem to be confusing input with output here. Your use cases have generally been inconsistent and unlikely. I think you need to spend some time delineating exactly what situation you're trying to address.
Clear example is my incorrect knowledge of GMT.
GMT is not at all exceptional in the relevant respect, of referring to a specific offset rather than to a civil timezone. MST (aside from a Moscow-based interpretation) refers specifically to UT-7h, not to the dance that clocks perform in Denver. Likewise, MDT refers specifically to UT-6h. To accurately represent GMT and BST (as used in the UK) and MST and MDT (as used in north America) in the timezone database, you'd need essentially: Zone GMT 0:00 - GMT Zone BST 1:00 - BST Zone MST -7:00 - MST Zone MDT -6:00 - MDT and similarly for rather a lot of the other abbreviations. (It so happens that two of these four hypothetical zones are already in the database (GMT and MST), but that's unusual among the abbreviations.) If you don't do this, but instead have just links such as BST -> Europe/London, then at best it's still necessary to search within the timezone data to find out what the abbreviation means. That's not actually representing the abbreviation's meaning; it's a bad implementation of the hypothetical abbreviation-to-candidate-zone index. (Bad largely because it can only show one candidate zone per abbreviation.) (Note: I'm not taking a position here on whether abbreviation-based zones should be added the database in principle.) -zefram
Attached is some Perl code to extract abbreviation usage from the timezone database. This is essentially what's required to produce the index that would be required to decode abbreviations. On the current database it finds 316 distinct abbreviations, 173 referring to only one offset and 143 referring to more than one. A perusal of the output is enlightening regarding how abbreviations are shared, both clashingly and non-clashingly, between zones. -zefram
On Dec 8, 2011, at 10:14 AM, Zefram wrote:
GMT is not at all exceptional in the relevant respect, of referring to a specific offset rather than to a civil timezone. MST (aside from a Moscow-based interpretation) refers specifically to UT-7h, not to the dance that clocks perform in Denver. Likewise, MDT refers specifically to UT-6h.
To accurately represent GMT and BST (as used in the UK) and MST and MDT (as used in north America) in the timezone database, you'd need essentially:
Zone GMT 0:00 - GMT Zone BST 1:00 - BST Zone MST -7:00 - MST Zone MDT -6:00 - MDT
and similarly for rather a lot of the other abbreviations. (It so happens that two of these four hypothetical zones are already in the database (GMT and MST), but that's unusual among the abbreviations.)
If you don't do this, but instead have just links such as BST -> Europe/London, then at best it's still necessary to search within the timezone data to find out what the abbreviation means. That's not actually representing the abbreviation's meaning; it's a bad implementation of the hypothetical abbreviation-to-candidate-zone index. (Bad largely because it can only show one candidate zone per abbreviation.)
Dang, I think that would be a much better solution, for me. It would decrease access time of information retrieval, if I get it right. I will research as a possible solution, for me. Thank you! The information I provided should not be considered an authoritative work. I am a peon in the grand scheme, and provided in hope that it may be of some use. I am not even in a position to take a position on adding data to the database. Steve
participants (11)
-
Andy Lipscomb -
Eric Muller -
Guy Harris -
Jaakko Hyvätti -
John Haxby -
Mark Davis ☕ -
Russ Allbery -
Steve Allen -
Steven Abner -
Thom Hehl -
Zefram