Hi, all, Please take this discussion to ART (art@xxxxxxxx) Joe On 3/28/2017 10:39 AM, Nico Williams wrote: > On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote: >> Yes, the system should use a leap-second-free constant-duration-seconds time >> for everything. It is only humans that need the variable jumpy version of >> time presented to them, and that is a UI issue. > I don't think that's quite right. > > Unix time is canonically a count of seconds since an epoch and admits no > leap seconds. A conversion of Unix time to adjusted (i.e., with leap > seconds added) time since the same epoch would be nice, as well as: > > - conversion from either to broken down time > - with seconds count up to 60 when converting from seconds-with-leaps > - formatting of dates from either as well as from broken down time > - but when converting from seconds-with-leaps the formatted string > can show seconds-in-minute values of 60 > - whereas when converting from Unix seconds the formatted string can > never show seconds-in-minute values of 60 > - parsing to broken down time and to seconds-since-epoch types > - ignoring leap seconds when converting to Unix time > - correctly accounting for all leap seconds prior to that time when > converting to seconds-with-leaps-since-epoch > > It's all about data typing. In POSIX C API terms, we need new functions > to deal with seconds-with-leaps-since-epoch, and obviously a lot of > prayer because there's no way in C to distinguish one integer type from > the other (well, the new type could be wrapped in a struct..). > > We will have to deal with multiple kinds of time as long as different > applications/users need different definitions of time. Astronomers may > need corrected time, while bankers may want to ignore leap seconds -- > all on the same systems (same OSes, same code libraries). > > Functionally this is about data typing -- preferably strong data typing. > > Smearing is a third time representation that also needs conversion to > the other types (more opportunity for bugs!); it leaves a bad taste. It > may work for some apps though, but all nodes had better smear in exactly > the same way -- within your tolerances -- if your app depends on time > for synchronization. > > Nico