[ntp:questions] Number of Stratum 1 & Stratum 2 Peers

Martin Burnicki martin.burnicki at meinberg.de
Wed Dec 17 13:24:41 UTC 2014

Rob wrote:
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> Imagine you set up an event for April 2015 today, but you just don't
>> know if DST will be in effect at that time, or not, just because the
>> politicians haven't made the decision today. How will you handle this?
>> It may not be helpful if you get updated DST rules the day *after* the
>> scheduled event.
>> On the other hand, when the event time approaches and you have the
>> chance to get a DST rule update before the event time everything may be
>> fine, if a decision is taken either to keep the UTC time *or* the local
>> time for this event.
>> Since UTC is actually used in most computers to keep the system time and
>> schedule events based on an accurate UTC time it may not be helpful to
>> do this with post-processing.
> It depends on what kind of event it is.  When it is a "human event" like
> a meeting, it is customary to plan these events in local time.

"It depends" even more. The tzdist folks are planning to use a reference 
to a specific time zone instead of the TZ rules which have been in 
effect when the event was created.

I've recently posted some consideration on the tzdst mailing list:

> So they
> should be stored in local time with a specified timezone.  What UTC time
> this is will depend on the local time rules at the actual event time.
> It will still be tricky when you plan a meeting at 02:30 on the sunday
> of the DST change from summer->winter time.  You cannot add a DST flag
> with the event because you cannot know if there will be a DST change at
> that time.  Of course that is why the DST change is done at a moment
> where such problems are unlikely, and not for example at 12:00 on the
> first day of the month.

That's why IMO they should be stored in UTC time (or even TAI, if that 
was possible), and only presented to the user in preferred local time zone.

I've posted some thoughts for the case that the TZ/DST rules change 
afterwards in my email behind the link above.

> Some calendering software gets this wrong, yes.  E.g. by converting the
> specified local time to UTC time and storing that.  This has caused
> problems in the past for well-known calendering software, I don't know
> if that has been fixed.
> For "technical" events it may be different, and storing them at the UTC
> time could be better.  But scheduling software (Windows Scheduler,
> Unix cron) usually uses local time as well.

Unfortunately it seems to be common practice today to write software in 
a way it is quickly ready and works in most cases, without thinking 
about different cases or what happens if anything is not as usually 

See the discussion about the expiration date of the leap second table. 
It is not hard to implement this, and if it is supported it allows 
software to be written in a user-friendly way which allows to generate a 
warning to users or admin saying that interaction may be required, e.g. 
information (leap second tables, DST rules) need to be updated.

Of course you can say a good admin has to take care of this, but I'm 
sure an admin would be happy if he received a reminder just in case he 
doesn't remember a specific task.

And of course you can say this works perfectly without expiration date 
if every tiny client gets the current data via an SSL connection 
directly from NIST, IERS, or IANA, but if you *do* provide an expiration 
date both this works nevertheless in the same way, but allows for 
extended usage which is more user-friendly and thus avoids potential risks.


More information about the questions mailing list