Howdy, I could use some input. I have a different database, lots of reasons for it, which has the attached file as part of the database. I am not an international person, nor is my code yet patented, since the big corps won't take this seriously unless it is. This file was created out of necessity for implementation of operating system functions and a bridge between user and your database, or so I think. Even if you think my thoughts on the intro are invalid, please respond. My initial intent was to submit this for you all to use, but I have already assumed that it will be rejected, the norm! So please, any international users fell free to make suggestive comments. I am in the process of trying to fully automate the list generation, have to hand work some. It has been tested for the strptime(), getdate() and strftime() functions and found not lacking. Of course, this is from test cases I have to think up, since none of the functions I have tested can handle time zones. I am still testing, and re-evaluting for debug-ability and optimizations, so this is not set in concrete. If tz peoples would like to adopt this file, cool! The zic compiler will handle, but your file retrieval will probably need to be altered some. Can't help you there, sorry, different system. There are some notes in the file. In particular this could sate those that aren't fond of the Australia zones and may make Indonesian peoples happy. It addresses, hopefully, French, German and Brazilian peoples too. Off list input also accepted. Steve pheonix@zoomtown.com
On Tue, 06 Dec 2011, Steven Abner wrote:
I could use some input. I have a different database, lots of reasons for it, which has the attached file as part of the database.
You didn't explain what you were trying to do, so I had to figure it out from the file attachment. Let me try to explain it for others. If I have correctly interpreted your intention, you want to make it easy for software to interpret time zone abbreviations in user input, and to that end you suggest making a lot of abbreviation-based time zones to supplement the existing location-based time zones. Essentially, for each abbreviation that appears in the existing location-based time zone data, you would create another time zone whose name is based on the abbreviation and whose definition is a link to the location, and you would have some sort of method for resolving conflicts where the same abbreviation is used by multiple time zones. You would also add some other abbreviations with other simple definitions, such as the "military" time zones A to Z. For example, given the existing definition of Pacific/Chuuk: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Chuuk 10:07:08 - LMT 1901 10:00 - CHUT # Chuuk Time and given that the abbreviation "CHUT" is unique, you would add this link: Link Pacific/Chuuk Abbr/CHUT Once you have this, software that receives the string "CHUT" in a context where a time zone name would be appropriate, can try using the "Abbr/CHUT" time zone to make sense of it. This seems fairly useful to me, despite the obvious problems with non-unique abbreviations. --apb (Alan Barrett)
Alan Barrett wrote:
This seems fairly useful to me, despite the obvious problems with non-unique abbreviations.
There's a conceptual problem regarding what the abbreviation means. For example, one of the proposed links is BRT -> America/Sao_Paulo. Sao Paulo has a pattern of DST whereby it's on UT-3h, called "BRT", during the southern winter, and on UT-2h, called "BRST", during the southern summer. So it appears that the real meaning of the "BRT" abbreviation is a fixed UT-3h. If a zone named "BRT" has behaviour other than that fixed offset (and fixed abbreviation), that's going to be surprising. In fact, the list also suggests BRST -> America/Sao_Paulo, making BRT and BRST synonymous for that purpose, even though they're clearly not synonymous in common usage. This would be even more confusing if, say, "GMT" were interpreted to mean Europe/London, which switches between GMT (UT+0h) and BST (UT+1h). Funnily enough, the list does suggest both GMT -> Europe/London and BST -> Europe/London. Even for zones that currently are on a fixed offset, historical changes are a problem. CHUT -> Pacific/Chuuk yields a surprising interpretation of "CHUT" prior to 1901. If you're going to define zones based on the commonly-used abbreviations, the zones should reflect the actual meaning of the abbreviations. These don't correspond to existing geographical zones. -zefram
participants (3)
-
Alan Barrett -
Steven Abner -
Zefram