Computing desk
< December 31	<< Dec \| January \| Feb >>	January 2 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 1[edit]

why is the insertion of leap seconds such an issue for software?[edit]

The corresponding article to it gives some hints. However how does it crash a Windows or Linux server? And why readjusting the clock (by hand or automatically) won't crash the system? — Preceding unsigned comment added by 31.4.142.11 (talk) 11:56, 1 January 2017 (UTC)[reply]

This is a topic that isn't easy to describe to a non-programmer audience. It is rife with technical details. If you aren't familiar with how computer programmers use computer hardware and software to represent time, start by reading Real-time clock and system time. If these subjects are too technical, please accept this summary: there is a lot of complexity involved in getting a high-speed digital computer to understand time in the format that humans expect. Small errors can occur in any of the layers of the system that work with the clock.

A large number of totally distinct bugs might occur in response to the UTC leap second; among the most common category of bugs are softwares that incorrectly assume a monotonic increase in system time. When time is reported by certain programmatic conventions, monotonicity is not guaranteed. This means that it is not correct to use simple arithmetic to compute time-differences between two arbitrary time-stamps: a sophisticated API must be used to ensure accurate and valid time interval calculation results. Failure to use such an API may yield negative, zero, or other wrong values. Software that uses wrong time interval values may propagate a malformed result, yielding a crash.

An excellent technical overview is presented in the Java language utility java.util.date, including links to further discussion.

A different category of bugs arise from the time zone and leap-second database. Computers must interpret a complicated database file and decode the schedule for when a leap-second is due. This database file is updated, and modern computers must retrieve a new copy from a trustworthy source. The most common format for this data file is the tz database. Read and understand its specification; it is documented by IANA on their website and in RFC6557 and RFC5545 and RFC4833 and ISO 8601 and ... any skilled programmer will recognize that correct and complete handling of this format is prone to human-error. If a human-error persists in software that runs on your computer, your computer may execute undefined behavior ...(it may "crash").

In other programming environments - like linux kernel - things get even more complex, because software must also deal with machine-specificity. Here is a mail archive for Kernel's handling of ISO 8601: a patch to mktime64. Here is a discussion of how leap second impacts secure execution in kernel 2.6 (... which is now "quite old"): ChangeLog-2.6.34.13. On some computer architectures, the system clock is part of the security scheme, largely to preclude replay attacks (or to make replay attacks tamper-evident by use of a nonce or hardware counter). Weirdness with the leap second causes certain benign activity to look an awful lot like a replay attack. Software in the kernel must handle this case correctly, else it may perform undefined behavior. Our eagle-eyed readers will observe that the kernel hackers attribute the correct implementation of the UTC leap second algorithm to Carl Friedrich Gauss. This is, surely, an anachronism for the sake of humor. Ha!

There are immense variations on these themes. Ultimately, to understand how any specific software might fail when face with any specific instance of a leap-second, we need to carefully scrutinize its source-code. But we can lump the failures into general broad categories: arithmetic errors caused by wrong assumptions about timestamps; system errors caused by incorrect or esoteric handling of hardware clock counters; application errors caused by invalid time-zone and localization computation; and so on.

Here's a great introduction to time programming, from W3, the web standardizations consortium: Working with Time Zones.

Hopefully this helps direct you to technical resources. If all else fails, learn to use the thinnest, lightest, all-aluminum computer around: the E6B, whose analog time-calculation capabilities are numerous and widely useful.

For the regular readers who are not familiar with my background, I used to build high precision clocks based on GPS radio signals, and participated in research that used tiny satellite clock errors to indirectly measure the imperfect character of Earth's ionosphere, through which all GPS signals must propagate. The core feature of GPS technology is a group of incredibly accurate clocks that can be used to triangulate an incredibly-accurate location. We would use sophisticated analog and digital electrical circuits, and special software-enabled computers, to ensure clock coherence on opposite sides of the Earth. With effort, we can obtain nanosecond-accurate clock coherency across thousands of miles - as long as we are very very careful. These days, as I pursue an instrument pilot rating, I am engaged in an ongoing metadiscussion with my flight instructors about the trustworthiness of software computers to correctly perform these calculations. Famously, a group of very smart scientists accidentally forgot a tiny software-detail related to a GPS time stamp, and mistakenly believed that they had found faster-than-light communication. Very smart people can make very small errors, and software makes these errors impossible to identify. It is for this reason that, when I can't rely on my eyes and ears, I still trust my stopwatch more than my sophisticated GPS-enabled computer. Think of the speed of light as a very-high-gain time-error amplifier. To a GPS computer, each nanosecond of clock error equates to one foot of position error, which only becomes a problem when you're a few nanoseconds away from an obstacle you can't see. Nano-second errors in stopwatches are intuitive; nano-second errors in software are frequently incomprehensible. Good thing there is never any reason to believe that a software computer might err by one whole entire leap-second!

Nimur (talk) 17:35, 1 January 2017 (UTC)[reply]

It's rooted, I think, in a tradeoff between simplicity-that's-mostly-correct versus strict-correctness-that's-more-complex. Virtually all computer systems do all their timekeeping in terms of a simple, monotonic count of seconds since an epoch, the canonical example being Unix time. This scheme makes all sorts of clock, timer, and datekeeping programming much, much easier -- but there's no room in the scheme for leap seconds.

Moreover, there is real virtue in trying to make the programming easier. Date and time programming is notoriously difficult to get right -- and that's even when you make the simplifying assumption that you can do it in terms of seconds since the epoch.

But now, after we've been using the simplified representation for 40 years or so, it's really, really entrenched, such that it's nearly impossible to replace, or even alter significantly. The situation is made even more difficult if the reason for suggesting a change is something that only happens once every 18 months or so, and only lasts for a second -- i.e. something that seems so trivial (even though, to be sure, the problems of mis-handled leap seconds can be significant).

This ends up being a perfect example of a "New Jersey" versus "MIT" tradeoff.

Anyway, there are several classes of bugs and other things that go wrong:

When an operating system has no way to represent a leap second, but when a leap second does happen, the system has little choice but to repeat a second, or otherwise jump the time discontinuously -- but that glitch can destabilize any application program that's paying attention to time and that assumes that time flows continuously.
If an operating system tries to handle leap seconds "better", anything it does along those lines is likely to be unusual, meaning that it can similarly underline any application program that's paying close attention to time. Also, any code for handling leap seconds can only really, truly be tested once every 18 months or so.
There have been bugs that had nothing to do with leap seconds per se. One notorious example is that one version of the Linux kernel printed a helpful message to syslog saying that it was correctly doing its special once-every-18-months leap-second thing -- except it printed it in an interrupt context, when printing to log files isn't safe, such that the printout (not the leap second) sometimes caused the system to crash or hang.
Finally, as illustrated at this page, even the infrastructure that nominally is programmed to handle leap seconds -- namely the web of NTP servers -- cannot necessarily be trusted to do it reliably.

It's unusual for a leap second to actually crash a computer (but not unheard of, as the Linux kernel syslog issue shows). You asked why manually setting the time doesn't cause as many problems, and the reason is probably that manually setting the time is something that happens all the time, so it gets tested better.

In my spare time, I've been working for the past year (ever since this other thread) to try to improve leap second handling. I thought it would be reasonably straightforward, but I now fear even the incremental measures I had in mind may be nearly impossible. (And my experience is certainly not unique in that regard.) —Steve Summit (talk) 23:15, 1 January 2017 (UTC)[reply]

Well, the strict count of time units is the correct way to do things. I think that's pretty obvious. Leap seconds were a terrible idea from the start. I hope they will be expunged quickly. --Trovatore (talk) 20:41, 2 January 2017 (UTC)[reply]

Well, without leap seconds you will eventually have the same problem as without leap years - only about 7 orders of magnitude later. --Stephan Schulz (talk) 20:58, 2 January 2017 (UTC)[reply]

Which is worse: having Christmas in the middle of a northern summer or having sunshine all night and darkness all day? We would, in practice, replace leap seconds with a leap hour at some stage, and GMT would be redefined or abandoned for civil purposes instead of the current fudge where Big Ben was slowed down during December 31st. Dbfirs 21:42, 2 January 2017 (UTC)[reply]

What language that is interpreted that is usually considered the best one?[edit]

What language that is interpreted that is usually considered the best one?201.79.48.89 (talk) 16:50, 1 January 2017 (UTC)[reply]

It depends what you mean by "best" (e.g. easiest to learn; most powerful; fastest; most likely to get you a well-paid job, etc), and also by interpreted language, which is not a clearly-defined term. AndrewWTaylor (talk) 17:30, 1 January 2017 (UTC)[reply]

"Best" is undoubtedly a matter of opinion; please see the header at the top of the page, which states, "We don't answer requests for opinions, predictions or debate." If you want to ask a question with a factual answer, like "What are the most widely-used interpreted languages today?", we would be glad to give some answers. --47.138.163.230 (talk) 21:35, 1 January 2017 (UTC)[reply]

LISP 110.22.20.252 (talk) 22:35, 1 January 2017 (UTC)[reply]

The best language is, of course, and with no debate, C. But Scheme gets a honourable mentioning because it's most likely to expand your brain in interesting ways. --Stephan Schulz (talk) 06:46, 2 January 2017 (UTC)[reply]

No common implementation of C is an interpreted language, davidprior ^t/_c 13:31, 2 January 2017 (UTC)[reply]

But there are uncommon ones (although they lose most of the charm of C). I stick by the Greater Truth ;-). --Stephan Schulz (talk) 15:13, 2 January 2017 (UTC)[reply]

Among the most popular C interpreters, CINT still has a fairly strong following, and cling is an even newer replacement based on clang. If you are familiar with lldb, you already know that its expression evaluator is darned similar to a C interpreter and hardware-emulator. It also "seamlessly" blends with the built-in python interpreter.

Nimur (talk) 16:58, 2 January 2017 (UTC)[reply]

I used cint and now use cling extensively in C/C++ classes. I believe that it is necessary to see code operate step-by-step to really understand what it is doing. Yes, you can use a debugger. I find interpreters to be nicer when all you really want is step-by-step operation. In class, in real time, I can write code and interpret it. I don't have to compile it and then debug it. I wouldn't claim that interpreted C/C++ is "common" though. I use it for strictly academic purposes. Of course, I do the same in other classes from Java to Node.js. I find a way to step through the code and show exactly what is happening each step of the way. So, it isn't just a C/C++ thing. 209.149.113.5 (talk) 18:09, 2 January 2017 (UTC)[reply]