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

Rob nomail at example.com
Wed Dec 17 10:05:01 UTC 2014

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.  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.

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.

More information about the questions mailing list