Paul Eggert > INTERNET:eggert@twinsun.com wrote:
I agree with most of Markus Kuhn's comments and have the following further comments and suggestions.
* I agree with Markus that ambiguous local times are a problem, but the proposed A/B notation is not an adequate solution. That notation works in the European context, where the rules are simple and uniform, but it won't work well in general and it's painful to implement reliably.
(major snip dealing with problems with A/B notation)
Here's a counterproposal that avoids the above problems. Instead of having a special A/B notation for ambiguous local times, simply have section 6.7 require the UTC offset. That is, instead of
1996-10-27T02:30:00A Europe/Paris [+02:00] 1996-10-27T02:30:00B Europe/Paris [+01:00]
(where the bracketed items are optional), require the UTC offset instead:
1996-10-27T02:30:00 Europe/Paris +02:00 1996-10-27T02:30:00 Europe/Paris +01:00
This counterproposal simplifies the notation and removes options, which is a stated goal of the draft.
I completely agree with Paul Eggert's suggestion.
* In practice the choice of time zone rule names may be controversial. To encourage standardization and head off as much controversy as possible, I'd like to echo Markus's suggestion to add (to the draft's section 6.3) as much as possible from the advice to submitters of new time zone rule names, taken from the `africa' file of the <URL:ftp://elsie.nci.nih.gov/pub/> registry.
My advice here would be to avoid using time zone names/acronyms, period. After all EST means either -05:00, +10:00 or +11:00 depending on nationality and time of year. If, however, time zone acronyms and names have to be used, I would urge 'daylight time' instead of 'summer time' as both standard and summer begin with the same letter, creating further confusion; in Australia, EST can be either +10:00 or +11:00 as mentioned above. Chris Carrier