Re: [tz] [PROPOSED] Use "PST/PDT" for Philippine time
Michael H Deckers wrote:
Fine if this were a generally applied guideline -- but it is not, see eg America/Adak, Indonesia, and many others. When is this guideline applied, and when not?
The guideline is supposed to be applied reasonably consistently for clear-cut cases such as the Philippines. Alaska and Indonesia are more complicated, since they are not merely a question of what's the name of a time zone; they are also a question of time zone boundaries moving, and where it's not so clear what is being named. For example, a historian today would be unlikely to write "Sitka observed Alaska Standard Time in 1984" because in 1984 the Alaska time zone boundaries were quite different and Sitka was then in the geographically small part of Alaska that was in the same time zone as the Yukon. Unfortunately I don't see a good solution for these more-complicated cases, and am reluctant to change the data if it's likely this would introduce as much or more confusion than it would alleviate.
And all that does not justify the resurrection of an invented abbreviation.
First, for the Phillippines it's no longer an abbreviation that exists only because we invented it. It's taken on a life of its own in reliable sources and in national law. And second, I doubt whether these sources got "PST" from tzdb, since tzdb has been using "PHST" for over two decades and used "PST" only briefly before that. Most likely it was independent reinvention.
On 24/06/18 17:24, Paul Eggert wrote:
Unfortunately I don't see a good solution for these more-complicated cases, and am reluctant to change the data if it's likely this would introduce as much or more confusion than it would alleviate.
Being practical one would hope that any 'tz geolocate' RFC would have provision to handle the history of changes in appropriate ruleset being used. Where this is a lot more complicated is where the current rulesets incorporate historic changes, but those are no longer visible to 'default' users. Pre-1970 changes in 'location' resulting in a different rule set being used should override the 'current' ruleset for a location. The whole system SHOULD return 'don't know' where data is simply missing for whatever reason, and using current data blindly with historic timestamps will always be wrong! That there is not an authoritative source for that data currently is no reason to assume any other answer? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Date: Mon, 25 Jun 2018 10:16:05 +0100 From: Lester Caine <lester@lsces.co.uk> Message-ID: <cf68c796-2db1-a653-262b-3a55aeeb27f7@lsces.co.uk> | The whole system SHOULD return 'don't know' where data is simply missing | for whatever reason, You can design a whole set of new interfaces with that kind of return available if you like. Traditionally localtime() was expected to always succeed (there was no error return possible at all) - that needed to be altered when the "int" tm_year became too small to translate all time_t's but that's the only error now. | and using current data blindly with historic | timestamps will always be wrong! Using current data for future timestamps is just as likely to be wrong. But regardless of that, getting something relatively close to correct is adequate for 99% of the uses that exist. For historic values, while the zone data might not be correct, the recorded timestamp is just as likely to be even more incorrect (or vague) so the loss there is not as great in most cases as it seems it could be. kre
participants (3)
-
Lester Caine -
Paul Eggert -
Robert Elz