[tz] Policy Suggestion: Minimum time period betwen releases

John Sauter John_Sauter at systemeyescomputerstore.com
Mon Mar 27 17:00:22 UTC 2023

On Mon, 2023-03-27 at 12:46 -0400, Howard Hinnant via tz wrote:
> Recent events have brought to my attention the need to put a damper
> on chaos caused by poor planning.  When governments give little
> notice to changes in time zone rules, this is not a problem that this
> group can fix, or should even try.
> I propose a minimum period of 30 days between successive IANA tz
> database releases.  The train leaves the station no more frequently
> than once every 30 days (and will probably be less frequent). 
> Whatever information is solid before the release date makes it on the
> train.  Otherwise it can wait another 30 days (at least).
> My recommendation is in part based on this common statement:
>     Poor planning on your part does not constitute an emergency on my
> part
> https://www.incirlik.af.mil/News/Commentaries/Display/Article/303134/poor-planning-on-your-part-does-not-constitute-an-emergency-on-my-part/
> This week’s chaos isn’t unusual.  In fact it is normal, especially
> for some countries.  If they can’t be bothered to make a plan in
> advance and stick with it, I don’t see why this group of volunteers
> needs to compensate for that.  Let the politicians lie in the beds
> they make.
> Howard

I don't agree.  I think the maintainers of the time zone data base
should have the flexibility to release an updated version whenever, in
their considered judgment, they feel a release is necessary.

An obvious case is a serious typographical error.  As soon as it is
discovered, even if only a day after a release, it should be possible
to correct it.  I am not referring to a typographical error in a
comment but one that causes the time to be incorrect.

Also, it is sometimes helpful to make bad political decisions very
visible.  Doing so can encourage the makers of bad decisions to mend
their ways.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
get my PGP public key with gpg --locate-external-keys
John_Sauter at systemeyescomputerstore.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://mm.icann.org/pipermail/tz/attachments/20230327/81a8e6f2/attachment.sig>

More information about the tz mailing list