[tz] [Tzdist-bis] [calsify] tzdist and IANA

Daniel Migault daniel.migault at ericsson.com
Thu Jul 18 13:07:57 UTC 2019

adding the tz mailing in the discussion


On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki <
martin.burnicki at burnicki.net> wrote:

> Eliot Lear wrote:
> >
> >> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki at burnicki.net>
> 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
> _______________________________________________
> Tzdist-bis mailing list
> Tzdist-bis at ietf.org
> https://www.ietf.org/mailman/listinfo/tzdist-bis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190718/d637910a/attachment.html>

More information about the tz mailing list