On 12 April 2013 07:16, Ian Abbott <abbotti@mev.co.uk> wrote:

That's all the more reason to add the 'A' prefix to the new abbreviations, I think, just so it's easier to tell if an old date string is using the old abbreviation or the new one.

On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:

I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue

A different issue, certainly. But I think the argument here is that, although it can be discussed separately, adding the A should probably be implemented simultaneously with the broader xST/xDT change. If we don't, we could potentially have legacy timestamps out there stamped by versions of tz that use (1) xST/xST, (2) xST/xDT, and (3) AxST/AxDT. In the third case, nothing is ambiguous; but between the first two, the question of whether it's ambiguous is itself ambiguous!

On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:

We changed only the daylight time abbreviations to end the ambiguity.

Unfortunately, as shown above, this could actually make it worse. Since a goal of this broad proposal is indeed to reduce ambiguity, we should be extremely cautious against introducing ambiguity within ambiguity. Obviously, we can't change the past (and we shouldn't attempt to), so it is better to make a clean break and add a clear distinction between the two different notations so it is clear which is being used (and in the case of the older one, so users can decide whether further investigation is required to disambiguate).

On 12 April 2013 09:34, Stuart Bishop <stuart@stuartbishop.net> wrote:

I believe nearly all Australians either don't care or prefer AEST over
EST

In many ways, this helps, too. We have, at hand, a natural way of adding this distinction without resorting to inventing abbreviations (which we should not do).

On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:

But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.

In short, I support both the xST/xDT and the A changes, and I feel that the adoption of either without the other would subvert the very goals that each tries to accomplish on its own.

--
Tim Parenti

On 12 April 2013 09:34, Stuart Bishop <stuart@stuartbishop.net> wrote:

On Fri, Apr 12, 2013 at 7:17 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
> I believe both Timothy and I prefer prefer AEST over EST, but it is a
> different issue than the Daylight saving time ambiguity issue, so we agreed
> that we we should probably make only the minimal changes that resolved the
> Daylight ambiguity issue with the least changes, since it was more likely to
> be a proposal that would be accepted into tz. We changed only the daylight
> time abbreviations to end the ambiguity.

I believe nearly all Australians either don't care or prefer AEST over
EST, but understand your rationale. It solves the problems with
systems entirely inside Australian borders. Cross border stuff will
still need workarounds, such as international business or buggy
software written overseas, but at least it is progress.

> But if the tz maintainers believe that using AEST instead of EST would at
> the same time help resolve historical ambiguities caused by older versions
> of the tz database, I am sure we could re-roll the proposal to better suite
> the preferences of the maintainers.

I think a proposal for AEST would be preferable, with a fallback to
EST, rather than attempting to divine the desires of the maintainers
and end up with the less preferred option. Or was there an opinion I
missed?

--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/