Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

[Posted January 9, 2015 by corbet]

Wired talks with Linus Torvalds about the potential for another leap-second bug. "Really, to the rest of us, just take the leap second as an excuse to have a small nonsensical party for your closest friends. Wear silly hats, get a banner printed that says 'Leap Second Doomsday Party', and get silly drunk. You’ll blink, and it’s over, but at least you’ll have the hangover next day to remind you of that glorious but fleeting extra second."

(Log in to post comments)

Posted Jan 9, 2015 17:45 UTC (Fri) by deepfire (guest, #26138) [Link]

Here's another perspective on taking time:

http://www.wired.com/2012/11/google-spanner-time/all/

It's a Wired article, so naturally it is merely touching the surface.

TL;DR: Spanner is a system relying on atomic clocks for data synchronization.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 1:29 UTC (Sat) by kjp (subscriber, #39639) [Link]

Man is that a dumb article. It didn't talk about the big problem, time going *backwards* and confusing simple software. Speaking of which, when is UTC-SLS support going to be in ntpd or any other thin client? (Guess nobody besides google cares about reliability)

Also, last I looked at the man pages, I couldn't find *any* guarantees about threads seeing time going backwards after a CPU core migration. Again, I guess nobody who cares about reliability uses unix:-)

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 2:33 UTC (Sat) by dlang (subscriber, #313) [Link]

What OS do you run that doesn't allow the sysadmin to set the time? and if it allows the admin to set the time, but doesn't allow them to set it to some point in the past (as far as the system is concerned), how can the system ever get it's time corrected?

Any software that demands that the wall-clock clock never move backwards is going to break. Linux does provide a clock that's guaranteed to never move backwards, but as a result, it's not guaranteed to have a linear relationship with the wall-clock time.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 4:38 UTC (Sat) by jeff@uclinux.org (guest, #8024) [Link]

"Any software that demands that the wall-clock clock never move backwards is going to break"

You mean like 'make' for instance :) ?

IMHO and just IMHO, there should have been 2 layers of time in POSIX: A monotonic time like TAI and a correction layer providing UTC (which is actually the reality of atomic timekeeping anyway). But that's just me. GPS time is different yet again, but it is also monotonic, and the situation is quite frustrating and can be difficult to get right as it stands even for applications that care about such things (and lots of things need to, not just astronomy)...

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 6:19 UTC (Sat) by dlang (subscriber, #313) [Link]

> You mean like 'make' for instance :) ?

It's a good example, and it does break fairly regularly, and not just when time goes backwards. If you have a fast enough box to compile things in less time than your filesystem timestamps them, you run into problems as well.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 21:23 UTC (Sat) by zlynx (subscriber, #2285) [Link]

I think that the filesystem timestamps have been mostly fixed by storing nanoseconds in the cached inodes.

The system has to be under extreme memory pressure to discard the cached inodes fast enough that the missing resolution causes a problem. And in most cases where this is true the swapping and the delay caused by fetching everything from disk slows it down enough that again, the missing resolution is OK.

Maybe in the future of terabytes of NVRAM where the memory IS the filesystem and nothing is RAM cached, this will once again be an issue.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 19:31 UTC (Mon) by perlwolf (guest, #46060) [Link]

The cached inodes are a temporary fix. They only work as long as there are people running that make on a regular basis. After the development team comes back from a shared vacation, the cached inodes are likely long gone and then the next make has to guess about which of the many equally timestamped files is really newer than which.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 19:49 UTC (Mon) by zlynx (subscriber, #2285) [Link]

Huh. Good point. I was just thinking of make running from clean, but your explanation probably explains why I sometimes see things rebuild for no particular reason.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 16:50 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

If you have a fast enough box to compile things in less time than your filesystem timestamps them, you run into problems as well.

That seems like it's more a problem with make assuming that it's managing a slow, sequential process rather than a fast, parallel one and not a problem with the timestamps themselves. If make is the main program that's encountering timestamp problems, perhaps the solution is to change make rather than Linux.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 20:48 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Some of make's simplicity of design stems from the fact that it's entirely stateless. Or, perhaps more accurately, it relies on the filesystem to maintain all of its state, automatically.

If make were changed to consider some other criteria instead of or in addition to modification times, then it would have to store the state of the previous build somehow, so that the next build could use it for comparison purposes. That jump, from stateless to maintaining state, involves a lot more thought than simply adding new state to an existing mechanism.

Also, most additional state would necessarily reduce performance: file checksums and expanding variables to determine if the command line has changed are common ideas. These can be expensive. One simple and cheap idea is to check both the modification time and the file size... you get them both in the same system call (in POSIX), and clearly if a file's size has changed then it's been modified. This means a file would need to be modified both within the same microsecond (or whatever granularity the filesystem provides) AND that it end up with the same size after modification, which is less likely. However this is not as safe as some other possible tests, and it doesn't solve other problems such as changing a compiler option and wanting to rebuild.

I'm not saying that it can't be done, or even that it's massively difficult. I'm also not saying that you're wrong that make is (one) right place to tackle the problem. Just that there's more effort required than might appear at first glance.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 22:27 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Take a look at ninja[1] some day. I've basically replaced make where possible (autotools being the main holdout here since it's either that or CMake for the vast majority of projects). Nice things I get from it:

* much better speed (I've seen 50x for no-op builds, less for clean builds);
* recompile when command lines change (including flags);
* tools to inspect the build ("what's your plan?", "why are you running this rule?", graphviz dumps, etc.) in a *much* nicer format than make's -d flag;
* built-in 'clean' (no more forgetting files or greedy globs);
* NINJA_STATUS output so I know where the build is; and
* buffered output so that lines don't interleave.

Ninja does this with a "log" of what's been built and a "deps" "database" which remembers things like -MMD output. Both are not 100% necessary and can be removed without interfering with the state of a build tree (you might lose command line change detection, but that's no worse than make there).

[1]https://martine.github.io/ninja/manual.html

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 23:02 UTC (Tue) by zlynx (subscriber, #2285) [Link]

The real problem with these neat build systems is that in order to use them, you have to change away from the current working build system. This is pretty much useless work unless you're having a real problem with the current setup.

We tried using CMake for a couple of new C++ projects here, and it was OK. But reimplementing in CMake some of the things the GNUMakefile does for an older project are really cumbersome and difficult to implement. Like profile directed optimization. And we'd have to change the whole way the testing works. For no real point.

With CMake and with any other non-default build tools like Ninja, we'd have to build it for each system type. CMake on CentOS 5 was too old. FreeBSD didn't have it at all, as far as I could tell. Every extra thing that isn't a quick Yum or Apt or pkg_add install was another annoyance to setting up new buildbots.

Sometimes the pain of changing overrides any potential gains.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 3:48 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

FreeBSD has it (and a relatively recent version too, IIRC) since libpng requires it to build anyways. I agree that given an existing build system, moving to something else is a pain. The thing is that porting to Windows usually requires tossing out autotools for something else *anyways* (which is something I'm doing for a current project across 4 repositories which is interesting to juggle) and for all of CMake's warts, I still don't think there's anything better for the feature set it offers.

I also feel your pain with old CMake version requirements with all the nicities offered in 3.0 and 3.1. VTK is still 2.8.8 because of the target platforms (HPC) which just can't be upgraded without a lot of trouble. Luckily with CentOS5 largely off *my* radar now, 2.8.9 is now the next pin (via Debian stable).

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 15, 2015 1:00 UTC (Thu) by nix (subscriber, #2304) [Link]

libpng does not require CMake to build (not yet, anyway): it has an autotools build system too (and that's by far the most tested one).

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 15, 2015 3:22 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Interesting. FreeBSD uses it to build from ports at least[1]. I guess it is likely because of the BSD/GPL split and the fact that cmake is the only port necessary (versus autoconf, libtool, m4, likely perl transitively, and probably more).

[1]http://svnweb.freebsd.org/ports/head/graphics/png/Makefil...

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Feb 3, 2015 13:54 UTC (Tue) by nix (subscriber, #2304) [Link]

The whole point of configure is that you don't need any of that to build -- you get a nice shell script (well, a terrifying shell script) that does everything.

But maybe they're building from git, in which case they do need to build the configure script.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Feb 3, 2015 21:24 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

FreeBSD first started using CMake for png in mid-2012[1]. I agree that normally, you shouldn't need all the extra bits, but it seems that just about all of my jails have autoconf, m4, perl, etc. installed to get the end result (be it nginx, git, postgresql, etc.). I don't know why, exactly, they get pulled in everywhere, but I suspect some core package has patches for configure.ac or whatever and drags them in to rebuild configure.

[1]http://svnweb.freebsd.org/ports/head/graphics/png/Makefil...

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 15:58 UTC (Wed) by madscientist (subscriber, #16861) [Link]

Ninja is cool, but it's not really a user-facing tool. You usually need a separate tool, such as cmake, which can generate the Ninja files for you. This allows Ninja's runtime (parser) to be significantly faster as all the tricky parts are done by the front-end tool.

I'm not saying that this is a bad thing, at all: considering how often one changes the build control files vs. building the code, it's a very reasonable tradeoff. However, note that you're not just committing to Ninja you're also committing to whatever tool you use to generate the Ninja files.

As well, whereas Ninja has a clean slate to start from, make has other responsibilities: it must adhere to the POSIX standards, for example. Also GNU make has been around for more than 25 years and a considerable ecology has grown up around it, which ossifies even things like some output strings, etc.

I will point out, just FYI, that current versions of GNU make have a --trace flag which will print out information about each target that is rebuilt: filename and line number where the rule was defined, and information about why it was triggered (which prerequisites were out of date, etc.) Also, current releases have support for buffering output in parallel builds so they don't interleave.

[1] Some may say the same about writing raw makefiles, of course... :)

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 16:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

True. And it's a reason why gn isn't really something I imagine I'll care about too much: it only works with Ninja and Ninja has some things is just doesn't support (implicit order-only deps being the big one blocking proper Fortran dependency tracking). Anyways, my comment was mostly in response to this statement:

> Also, most additional state would necessarily reduce performance: file checksums and expanding variables to determine if the command line has changed are common ideas. These can be expensive.

since Ninja does the latter and is considerably faster than make (you don't really need the first unless starting from absolute scratch because people will want to support make anyways). And I've hit the fact that Ninja doesn't track nanosecond timestamps already[1].

Thanks for the info on gmake's --trace. Should help out next time I need to track down some add_custom_command weirdness :) .

[1]https://github.com/martine/ninja/issues/855

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 15, 2015 19:01 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

I guess that the reason I'm concerned about this is because something similar came up recently in a discussion of the security problems in NTP. The claim was that distributed make depends on clocks being synchronized to a high degree of accuracy. It makes me nervous that make is depending on the system providing a level of accuracy that systems aren't really capable of delivering. That makes me wonder about a couple of points:

1) Is make uniquely problematic, or is it just the harbinger of future problems that other programs will have with inaccurate timestamps?

2) Is make's problem really with inaccurate timestamps, or is that a sign that it's pushed past the point where it can safely assume that the filesystem can maintain all the state it needs.

These are related but still separate issues. It's possible that make is uniquely problematic but that it's important enough that the kernel developers will want to provide better timestamps just for its benefit. On the flip side, it's possible that the current timestamps will soon prove inadequate for lots of other applications but that make will want to start tracking state internally anyway. The latter seems like a more likely outcome, since make needs to run on more systems than Linux, and solving the problem internally will let it run on systems that can't provide adequate state themselves.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Feb 3, 2015 14:21 UTC (Tue) by nix (subscriber, #2304) [Link]

The problem is really timestamps. make's fundamental assumption is that if some program it is driving modifies a target, that that target will not still appear to be older than its source. The problem with NFS in particular is that the *server* is the thing that timestamps the file, and the server's idea of the time can diverge from make's idea of the time. If the server's clock is slower than the client's, then the server will timestamp a target then find it to be *still older than its prerequisite*; if its clock is faster, make might find a target to be newer than its prerequisite even though it was actually written before it.

It's possible, depending on your makefile, that this is unproblematic, but it is fairly easy to craft makefiles where a target gets updated more than once, or even (if the server's clock is *faster*) fails to be updated at all when a prerequisite is updated, though it is fairly likely that all targets will be updated at least once, as ploxiln notes. The warning make gives is just to note that this is not *always* the case.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Feb 3, 2015 15:19 UTC (Tue) by bfields (subscriber, #19510) [Link]

"The problem is really timestamps. make's fundamental assumption is that if some program it is driving modifies a target, that that target will not still appear to be older than its source. The problem with NFS in particular is that the *server* is the thing that timestamps the file, and the server's idea of the time can diverge from make's idea of the time. If the server's clock is slower than the client's, then the server will timestamp a target then find it to be *still older than its prerequisite*"

I think you also meant to specify that the prerequisite was on a different filesystem, or something. (If it was also on an NFS filesystem from the same server then the prerequisite's timestamp would come from the same clock.)

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Feb 17, 2015 17:53 UTC (Tue) by nix (subscriber, #2304) [Link]

True enough, though I didn't think of that. In hindsight, this is probably why most make warnings about clock skew are harmless: they're still using a single time source, it's just not the same one make(1) is.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 17, 2015 17:51 UTC (Sat) by ploxiln (subscriber, #58395) [Link]

Even without nanosecond resolution in the filesystem or cache, make isn't really a problem, because it considers a target with the same timestamp as a prereq to be up-to-date with respect to it.

Assume that an entire build completes in the same second.

Now, for things to work, the only additional assumption you need is that a change to a source file, either due to editing or fetching from some SCM, took more than a second after the previous build completed. That's a pretty easy.

Now, make can see that the source files which changed are newer than the others, even if it can't tell the order within each group. If you run a build, either during the second of the source updates, or the second after, the files which are older than the source-update second are considered out-of-date until they are rebuilt, even if that just updates their mtime by one second. It works out.

So, you merely can't run make *twice in the same second*, with second resolution file timestamps.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 14:04 UTC (Sat) by kjp (subscriber, #39639) [Link]

"guaranteed to never move backwards"

Please show me the man page that guarantees that when multiple cpu cores enter the picture (and e.g. rdtsc drift).

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 18:15 UTC (Sun) by pbonzini (subscriber, #60935) [Link]

If your rdtsc is broken, Linux will use an alternative time source.

You can also add protection on top. KVM for example prefers to keep the time stuck for some nanoseconds, rather than making the time go backwards.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 19:40 UTC (Sun) by kjp (subscriber, #39639) [Link]

It's too bad neither the linux man page or this http://pubs.opengroup.org/onlinepubs/9699919799/functions... gives any such explicit guarantee. Can CLOCK_MONOTONIC ever go backwards on a multi-socket system? Who the fuck knows. The documentation is atrocious, so why are we surprised when time bugs keep happening?

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 22:45 UTC (Sun) by k8to (subscriber, #15413) [Link]

I've seen situations where VMware is essentially responsible for migrating a line of execution from one core to another and therefore introduces TSC incoherence.

It can be really difficult to write software immune to the clock jittering around (for small values) every couple of milliseconds.

Granted, I'm describing misbehaving hardware, but I've encountered this sort of misbehavior in the double digits number of times (across our customer base).

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 16:56 UTC (Sat) by oldtomas (guest, #72579) [Link]

> Any software that demands that the wall-clock clock never move backwards is going to break.

There is at least one SMTP server which quits on time going backwards (Exim, IIRC), and I really can't blame the designer's decision.

I do work hard to avoid time jumping backwards on my servers (without a reboot in between, that is). If they're ahead of time by a reasonable amount (whithin a couple of hours), I just slow their clock down until the rest of the world catches up (to whithin the small margin where ntpd will take over). It actually isn't that hard.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 16:32 UTC (Sat) by ballombe (subscriber, #9523) [Link]

Why is time going backward ? Leap seconds so far have only been added, not removed, and I doubt there will ever be a negative leap second in the future: it would simply be merged with the next positive leap second. the dynamic is for the day duration to decrease.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 18:05 UTC (Sat) by drag (guest, #31333) [Link]

Clocks the computer has built-in have inherent levels of inaccuracy. That is why people depend on things like ntp to keep time in sync. Even worse is when you introduce power management features or use virtual machines were you suspend them and then there are great big jumps in time.

Occasionally because of these sorts of things time, from the program's perspective, will seem to 'go backwards' as the OS syncs up the time from external sources.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 21:08 UTC (Sat) by ballombe (subscriber, #9523) [Link]

OK but this issue has nothing to do with the leap second, so there is no reason for the Wired article to mention it.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 20:37 UTC (Sun) by butlerm (guest, #13312) [Link]

Why does time go backwards? Because the Unix encoding of time_t does not support leap seconds, so during the leap second the previous second, fractional seconds and all, is repeated.

UTC-SLS makes the clock run slightly faster than normal prior to a leap second so this problem is avoided.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 22:46 UTC (Sun) by k8to (subscriber, #15413) [Link]

The repeat is indeed odd, but it's not backwards.

Going backwards.

Posted Jan 12, 2015 6:42 UTC (Mon) by pjm (subscriber, #2080) [Link]

Counting to ten twice involves going backwards from 10 to 1.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 16:24 UTC (Mon) by butlerm (guest, #13312) [Link]

The integral number of seconds reported does not go backwards. The time returned by gettimeofday() or clock_gettime(CLOCK_REALTIME), including the nanosecond or microsecond part, does go backwards, because the fractional part is reset to zero while the integral number of seconds does not change.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 11:09 UTC (Sat) by sdalley (subscriber, #18550) [Link]

How about this New Improved Scheme for time_t ?

Since time_t has to change to 64-bit anyway, why not also union it with 2*32-bit ints? The most-significant-int could then be set to the number of *days* since the epoch, and the least-significant-int the number of milliseconds (or tenths of milliseconds) since the start of the day.

This would have the following advantages:
- the 64-bit form would remain monotonic. Simple time comparisons of "before", "same" and "after" would continue to work.
- The millisecond resolution would be an improvement on coarse seconds.
- Complete side-stepping of the leap-second problem, as leap-seconds are only ever added right at the end of a day.

The C standard specifically does *not* require that time_t be encoded in any particular form, hence specifies the explicit function difftime() to return the difference between two times. So the above scheme is not inconsistent with that.

What's the flaw?

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 13:32 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Since time_t has to change to 64-bit anyway, why not also union it with 2*32-bit ints?

The C standard explicitly states that time_t represents a number of seconds. The practical fact is that most existing implementations interpret that literally. Furthermore, the C standard does not permit implicit conversion from union type to primitive integer arithmetic type, which means that a <time.h> which honestly represents the change in semantics would break large quantities of existing source code that assumes you can treat time_t as a primitive integer arithmetic type (which, on existing implementations with significant deployment, it is).

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 23:47 UTC (Sat) by dfsmith (guest, #20302) [Link]

>> The C standard explicitly states that time_t represents a number of seconds.

The C standard says time_t is an arithmetic type that can represent the time (see, e.g., C99 ISO9899 ss 7.23.1(3)). You might be thinking of Posix/Single Unix Specification, which defines time_t as seconds from epoch.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 8:41 UTC (Mon) by fishface60 (subscriber, #88700) [Link]

I think the transparent_union attribute in https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#T... could be used to make a 64-bit time_t implicitly also 2 32-bit ints, since the restriction on the attribute is that all unioned types have the same machine representation.

It can't help with the ABI break of making time_t 64-bit unfortunately, so the current approach of leaving the 32-bit libc and kernel interfaces, but disabled by default, and having new code use the 64-bit versions of the interface (like the migration to 64-bit off_t) is needed to allow old binaries to still work, while new binaries use the 64-bit time_t, keeping the ABI compatible, while breaking the API to make it produce code for the 64-bit time_t interfaces.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 15:05 UTC (Sat) by Wol (guest, #4433) [Link]

> The C standard specifically does *not* require that time_t be encoded in any particular form, hence specifies the explicit function difftime() to return the difference between two times. So the above scheme is not inconsistent with that.

> What's the flaw?

That difftime neither knows nor cares about the difference between GMT and UTC? That it's going to confuse the hell out of programmers (who expect UTC) and users (who expect GMT)? And what on earth does the programmer-user expect? :-)

If I do a difftime on two middays one day apart, the *expected* result is "1 day". So if there's a leap second, do I confuse users by returning "1 day and 1 second" (fooling them into thinking there's some error!) or do I return "1 day" messing up programs that rely on sub-second accuracy?

For pretty much ALL of recorded history, we've managed pretty well with an inaccurate geo-clock. Now we've got atomic clocks of near-perfect accuracy the *only* solution that is really going to work is to throw out all our old geo-clocks and create a new time-keeping mechanism, with a translation layer. Any other solution is almost certainly going to play havoc with one use-case or another.

Cheers,
Wol

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 10, 2015 19:47 UTC (Sat) by jwakely (guest, #60262) [Link]

C guarantees it's an arithmetic type, which means integer or floating point type, not a union type.

And such a type would not be "uniquely represented" (as defined in Stepanov's Elements of Programming), meaning the time_t value representing a given time point could be expressed by more than one bit pattern. Given one of your time_t objects, if I add 1000 * 60 * 60 * 24 to the 32-bit milliseconds member, and subtract 1 from the 32-bit days member, do I have an object representing the same time point that I started with? It certainly won't compare equal if I just compare the 64-bit integers.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 11, 2015 21:14 UTC (Sun) by Wol (guest, #4433) [Link]

That's easy to solve ... or is it?

Just say that a canonical day cannot have more than 24*60*60+1 seconds in it, and that comparing non-canonical dates is undefined :-)

That, however, could cause complications in a lot of industries where days are more than 24 hours long. But then again, these do have the same problem that any given time does not have a unique representation. Many industries don't reset the clock for shift workers on a shift, so a guy starting work at 23:00 will clock off at 31:00, the exact same time as the new shift will be clocking on at 07:00 the next day.

Cheers,
Wol

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 7:56 UTC (Mon) by josh (subscriber, #17465) [Link]

> Just say that a canonical day cannot have more than 24*60*60+1 seconds in it, and that comparing non-canonical dates is undefined

Three words that make any programmer working on calendar time systems cry: Daylight Saving Time.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 12, 2015 20:18 UTC (Mon) by Wol (guest, #4433) [Link]

:-) :-) :-)

struct time64_t ?

First element being a 64bit signed integer count of milliseconds since an arbitrary time 0. That gives us +-300million years :-) This is defined as being accurate, so it would make sense that all positive times are atomic clock times, all negative times are geo-clock times. Dunno what that makes our time zero, but it would be when the atomic clocks were "switched on" for timekeeping.

Second element being a bunch of flags which indicate how to display the time. This will need to be initialised, either to the system default or to zeroes if it's not stored with the 64bit time.

But that then gives us a whole bunch of useful abilities :-) Like storing the offset so when somebody sends me a request for a meeting "at 12:30pm BST" I can tell whether they mean UTC+1 or UTC-6. And the calendar - is the date Julian, Gregorian, Japanese Imperial, Hebrew, whatever? Do I display GMT or UTC? There's an awful lot of context information in dates, which a simple time-stamp loses.

And it would also make conversion between times so much simpler - we could have functions which say "given a second element like this, convert this date and time to the matching 64bit time". So if as a historian I have a whole bunch of dates between about 1550 and 1917, from Europe, the Anglo-Saxon world, and Russia, I can dump them all into this structure and compare them without getting thoroughly screwed up trying to remember which dates match what in the various calendars.

And it would push daylight saving into the library :-)

Cheers,
Wol

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 13:29 UTC (Tue) by niner (subscriber, #26151) [Link]

The correct way of dealing with daylight saving time is to correctly handle time zones. DST does not change the time. it changes the time zone you're in. Within a time zone, a day indeed cannot have more than 24*60*60+1 seconds in it. And if you handle time zones correctly, a calendar entry that starts in one time zone and ends in another (like a typical long distance flight) is no troubly anymore.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 13, 2015 17:41 UTC (Tue) by josh (subscriber, #17465) [Link]

That's not how any modern system handles DST. Time zones define when DST starts and stops, and the system handles that by repeating or skipping an hour.

Now, for a system that sensibly keeps its clock in UTC and treats the time zone purely as a means of obtaining local calendar time, timers set in UTC won't have to deal with those missing or duplicate hours. However, software that has to deal with the local time zone and calendar time, such as a calendar, has to care.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 8:24 UTC (Wed) by dgm (subscriber, #49227) [Link]

> Within a time zone, a day indeed cannot have more than 24*60*60+1 seconds in it.

Then a timezone is of no use, because the user's day can really be 23 or 25 (or whatever) hours long. The purpose of calendaring applications is to reflect the real user's day.

If you need monotonic time what you should be using is UTC or, even better, TAI.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 12:56 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

How do calendaring apps show that week then? Is there a gap so one day has an extra hour? I think most iCal-based event editors only supports a timezone per event, so you're going to have to convert the time on one end of the event too.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 15:59 UTC (Wed) by jwarnica (guest, #27492) [Link]

Calendars don't care about seconds. As for hours, it happens Sunday morning, so it Doesn't Matter In The Real World. Or, Regardless Of What The Computer Does, People Will Be Confused.

For those that it does matter too, they are going to have some weird local rules anyway. Do you work 9 hour shifts, or 7? Drink an extra (or less) hour at the bar?

Anything that happens between 11PM the night before, and noon the day of a DST shift is going to require coordination of wetware.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 14, 2015 16:28 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I know; I don't think I've ever seen a gap in the ones I've used. Although if they *do* exist, that would be interesting to see just how such an oddball case was designed in the UI. One nice thing I saw was that a local pizza place changed their closing time from 3am to 4am that day to remove any confusion as to which 3am was closing time in November.

Linux’s Creator Wants Us All to Chill Out About the Leap Second (Wired)

Posted Jan 16, 2015 16:30 UTC (Fri) by meyert (subscriber, #32097) [Link]

Hopefully this time, somebody does test this... or we'll get another LWN article on 1.7.2015 :-) https://lwn.net/Articles/504744/