Re: [calsify] [Tzdist-bis] tzdist and IANA

[Martin Burnicki <[e-mail]>]

Eliot Lear wrote:
> 
>> On 18 Jul 2019, at 10:29, Martin Burnicki <[e-mail]> wrote:
>>
>> Hi all,
>>
>> Eliot Lear wrote:
>>> Hi everyone,
>>>
>>> While the IANA does a great job at servicing our assigned number needs
>>> and delivering the TZ database to developers, they is not set up, nor do
>>> they have *any* experience, to handle the load that end clients could
>>> place on them.  Moreover, they are in no position to support millions of
>>> people if something goes wrong.  And make no mistake: something will go
>>> wrong.  I would be okay with a limited tzdist service for those who are
>>> going to be distributing the data themselves, but the order of receivers
>>> should be on 100s not millions.
>>
>> Wouldn't it be nice to have an infrastructure similar to what the NTP
>> pool provides for time synchronization?
> 
> 
> I guess I would want to see commitment from those who provide TZ service to their customers today to go to such a new service before investing a lot of money.  Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the others want to use it?  I also realize that ICANN is well positioned to fund this sort of thing, but it is not clear to me that it is right for them to do so.  There has to be a real need, and those who really need it perhaps should foot the bill.
> 

I'm working at Meinberg
https://www.meinbergglobal.com/

and we are manufacturing NTP/PTP servers, beside related time
synchronization stuff.

In the past, whenever governments as of Egypt, Morocco, etc. decided to
start or end DST just a couple of days before this really happens we get
support requests from industries, telecommunication companies, etc.,
asking if our time servers could fix the problem to update the TZ data
quickly enough.

We always have to tell them they need to wait until a new TZ DB has been
released, and then hope that their OS maintainers (Microsoft, Apple,
Linux distros, etc.) pick up the new TZ DB version and provide a
software/firmware update just to provide the latest changes quickly.

Providing these updates also requires quite some effort for the
maintainers, and it would be much easier for them if this kind of
information could be updated automatically, which should also be faster
than with manual intervention required.

TZ data must not be requested from a server as often as the current
time, so I think that even if the data size is larger than an NTP packet
the overall load compared to NTP will not be much higher than for a
server that provides NTP services, and if I remember correctly then data
only needs to be transferred if changes have become available.

So I think this type of service and its advantages just need to be made
more public, to let the OS maintainers learn that they have less work
with rolling out and deploying software updates if they just use TZDIST.

I'd expect that a TZDIST pool could be operated by volunteers, just like
the NTP pool.

Martin