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