Alternative to A/B notation
72157.3334 at CompuServe.COM
Thu Jan 30 06:26:33 UTC 1997
Paul Eggert > INTERNET:eggert at 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
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.
More information about the tz