Den 04. jan. 2017 00:32, skrev Philip Homburg: >>> Time within the machine should be measured relative to its own temporal >>> frame, but whenever we communicate with another machine we need to >>> strive to be as close to UTC as possible - warts and all. Anything else >>> - including and especially smearing - compromises *correct* behavior. >> >> >> ?So you are for sticking with IPv4 as well? >> >> Nothing can ever change because the ITU is in charge...? >> >> ?People are only in charge as long as other people let them. ? > > The 'obvious' solution is to make programmers, from operating systems all > the way to application programmers, aware that there are different types > of time. > > Most programmers should already know that there is a difference between > local time and UTC. We need to extend that a bit. > > In particular, we need > - a monotonic 'uptime' that can be used for local timers, etc. independent of > any external time source. FWIW, the W3C has switched to defining time inside a Web page in two segments: - Page load time, which is UTC-derived (POSIX time extended to milliseconds), and can jump when the system clock is reset - Events related to the page load time, which has floating-point representation, and is guaranteed to be monotonic. DOMHiResTimeStamp and related specs make for interesting reading (although you'll feel at times like you're lost in a maze of twisty little definitions, all different). > - we need UTC. Civil time is UTC. We have no control over that. For many, > many years we know that leap seconds are a problem, but we are still stuck > with it. For many, many years we also know the daylight saving time is > silly. But we have good solution for the timezone stuff. > - we need a sensible time. There are many ways to define a sensible time, > but TAI is available, so let's use that. For me, sensible time includes > using SI seconds for keeping track of time. > > The main thing is that, by and large, this is not a network problem. If a > system uses TAI internally, it can use UTC for NTP, for SMTP, HTTP, etc. The > only thing we may have to do at the network level is improve the availability > of an up-to-date leap second list. > > The big thing is, making sure that operating systems offer TAI as a first > class citizen. Making sure that timers are set using MONOTONIC clocks and > making sure that applications that use subsecond precision for time > information internally use TAI and only convert to UTC for interacting > with users. > > Unfortunately, there doesn't seem to be an IETF equivalent for operating > systems, so it will be completely random whether anything will happen in > this area or not. >