Le 13/05/2017 à 11:27, Willy Tarreau a écrit : > On Sat, May 13, 2017 at 10:42:58AM +0200, Benoît GARNIER wrote: >> Le 13/05/2017 à 09:46, Willy Tarreau a écrit : >>> On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote: >>>> Time handling is not easy. I hate to say that, but POSIX and glibc >>>> manage to make it even harder. Especially the timezone global handling >>>> which is not thread-safe as you pinpointed. >>>> Anyway, free conding a simple timegm() is not very hard, since you don't >>>> have to take any timezone into account, only leap years. >>> That's what I've seen, none of them implement the leap seconds (I thought >>> it was needed). >> They don't because leap seconds don't exist. Really. The kernel (at >> least on Linux) hides this extraneous second(*) from userland. >> There are two ways the kernel can do this: >> 1) skipping it entirely - i.e the kernel will return 23:59:59 during 2 >> seconds > I disagree on this one, as the kernel doesn't return human-readable time > but only seconds and optionally micros/nanos. It's the tools and libc > which turn that into human readable format. And furthermore, I've seen > one with my own eyes by accident around 2000, so based on the list, I > think it was the 1999 one. That was the first time I've heard about > this. I spent more than one hour searching what bug in my system could > have caused a second to appear as "60" ! Yes, you're right, I was simplifying. The Kernel is in charge of keeping time, but userland keeps it synchronised (thru adjtime()). But still, the kernel has a notion of real time thru clock_gettime(CLOCK_REALTIME, ...) since it returns epoch. What I meant is that with *modern* Linux kernels / glibc, you won't see the extraneous second.
Benoît
