On Wed, Jan 04, 2017 at 09:21:29AM +0000, Stewart Bryant wrote:
On 03/01/2017 19:54, Cyrus Daboo wrote:
This is true, but any specific local time will always occur at a
specific universal time, so this isn't actually a problem.
No! That is not true because a future local time is not guaranteed to
be at a specific universal time because local government can change
their time zone (or more likely) their daylight savings time
transition at any time between now and said future time. i.e., you
cannot "pre-cache" all the local time -> UTC mappings for a future
recurring event and then just use the UTC values, because the time
zone definition may change.
So an application sensitive to that needs to specify its timing in
terms of local time, but that should not force the fundamental time
distribution system to operate in that mode.
Sure it does! If you want to interchange calendaring events (which...
people _do_) then those events must refer to local time, and they must
be stored in local time form. Otherwise the same issues Cyrus mentions
crop up.
This is hardly problematic. It just means that
a) every system needs to be able to convert to/from local time (but that
was _already_ the case even when you believed that local time was
only for interaction with a user) from using any and all timezones
(which was not already the case for you, but it's fine anyways),
b) (a) implies that tzdist is needed and TZ data has to be kept up to
date.
Maybe we need two time distribution systems, one that accurately does
the ranging and flywheel management and distributes precision time for
technical purposes, and a separate one that manages the offsets and
jumps relative to the underlying precision continuous time
distribution system.
Yes, of course.
Nico
--