[tz] Fiji DST Oct 26

[Tim Parenti]

On 21 October 2014 01:54, Clive D.W. Feather <clive at davros.org> wrote:

> Deborah Goldsmith said:
> > [...] The latter is far preferable for any tz client whose deployment
> cycle takes weeks or months.
>
> Actually, I'm not sure that's true.
>
> If we don't have any change in there and one happens, timestamps are wrong
> for months but it should be obvious to people that they are wrong and need
> correcting.
>

As Deborah alluded to, I think the key is the whether the deployment cycle
is long or short.  For many consumer devices these days (e.g., phones,
embedded systems), there are enough layers between tz and the end user that
short-notice changes like this simply won't make it to them in time.  In
that case, it's better to assume something slightly incorrect than to
assume no changes, since the end user may not be able to update the data
themselves, or may otherwise be resigned to employ kludgy workarounds.  If
the end user doesn't have a say in the matter, to simplify their lives,
it's better to have them experience mostly correct data than knowingly
false data.

This is in contrast to people administering more complex systems (e.g.,
servers, networks), who should presumably know enough about what they're
doing to be able to proactively (or at least reactively) seek solutions.

Obviously, it is a goal of the tzdist working group to reduce this number
of layers and/or the time it takes changes to propagate through them,
perhaps to a point where not assuming changes long-term becomes the more
reasonable option.

I don't think we're there yet, though, so I approve of Paul's conclusion.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20141021/65fb441e/attachment.html>