Keeping 'order' without RTC.

The point is that UNIX time is what it says it is - a monotonically increasing quantity that increases at a constant rate and is used to keep all the UNIX timings in sync.

Real time as such - human time, -is derived from it by a set of library functions that handle leap years and seconds and centuries and daylight savings: That is however merely a human convemntion. The real unix time is just 'seconds since 1970'

No they haven't. NTP sets it to the right UNIX time. And so too do any manual updates. They set the UNIX clock. by interpreting local time to be the correct unix time.

I strongly suspect real time clocks of the battery backed flavour ALSO are only counting the seconds from 1970, too.

All the 'user space' time is an illusion - a layer on top of UNIX time.

I mean the possible values of time_t (or struct timespec etc) as interpreted by Unix systems.

They are unlabelled. There is no value of time_t that corresponds to a leap second. The function converting a time_t to a UTC time is simply not capable of outputting a leap second.

Indeed. So the clock (specifically, CLOCK_REALTIME) is incorrect near leap seconds.

AFAIK that is only true if NTP is in use. But again, that just means the clock is temporarily wrong.

That?s what CLOCK_MONOTONIC is for.

OK, what is the Unix time representation of 2012-06-30 23:59:60 UTC?

Well, Wikipedia begs to differ.

Anyway if you could give me a reference for what you call Unix time, a reference from after the time when leapseconds were introduced, it would be helpful. Otherwise we will also simply be arguing about our own peculiar definitions of the terms.

Again, this sounds more like your interpretation than any specification.

Mills was involved in the design of the Linux time system, and that behaviour is part of the kernel behaviour AFAIK.

man adjtimex (which is a linux system routine, not an ntp one)

For Linux kernels 2.0 through 2.6, the value is a sum of these: 1 PLL updates enabled 2 PPS freq discipline enabled 4 PPS time discipline enabled 8 frequency-lock mode enabled 16 inserting leap second 32 deleting leap second 64 clock unsynchronized 128 holding frequency 256 PPS signal present 512 PPS signal jitter exceeded 1024 PPS signal wander exceeded 2048 PPS signal calibration error 4096 clock hardware fault o

(AFAIK it still behaves the same way in kernels up to 4.1)

?The number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds?. This is how functions such as gmtime() have always interpreted it.

It?s just a consequence of the definition. There?s no way to represent leap seconds, therefore the clock is wrong during them.

The behavior is in a file called ntp.c, which ought to be a hint. Where do you think the kernel learns about leap seconds from? If you?re not using NTP (or similar), it has no idea when they occur.

That?s not a Unix time. The answer to the question would be a time_t value. For instance, 1431456861 represents 2015-05-12 18:54:21 UTC.

And what do you think calls it?

The question is how does your definition handle leap seconds while they are occuring, and what backing do you have for your definition?

It is YOUR definition. Backing that anyone else uses it please.

No. That just means that David Mills, the developer of ntp was involved in defining the behaviour of the clock on Linux systems. You know better than to believe that the name defines the thing.

I am certainly NOT going to convert it to seconds. You may. My defintion was sufficient for you to figure out that on your own.

Anything that wants to call it. It is a system routine not an ntp routine. If you do not install ntp you still have that routine.

It?s not ?my? definition. It corresponds to the behavior of gmtime() in Unix systems. If you think it has some other behavior then I can only repeat my challenge to produce a counterexample.

I repeat: where do you think the kernel learns about leap seconds from?

Sure, I did. I told you how the kernel handles leap seconds. It is not undefined. I also told you how posix handles leap seconds. It is not undefined.

As far as I can tell gmtime assumes that there are 86400 seconds day, and leap seconds are not counted. That is exactly what UTC does. But the question is how do they handle leap seconds while they are occuring. gmtime is not supposed to handle that. It takes in a number and produces a date, by assuming, no matter what that number is, that there are 86400 seconds per day.

You can tell it, ntp can tell it, other programs can tell it.

That is irrelevant. the question is what does it do with it.

The kernel doesn't handle leap seconds.

Leap seconds are a human affectation. The kernel keeps UNIX time and thats all.

Well it doesn't update the UNIX clock with it, that's for sure.

The thing you have (still) failed to do is give a value X for which gmtime(X)=2012-06-30 23:59:60 UTC.

Yes.

No. 2012-06-30 had 86401 UTC seconds.

The question was about ?Unix time?. That?s precisely what the input to gmtime is. Based on previous discussion at this point you?re probably going to repeat your claim this is some personal definition unique to me, which is rather strange given ?my? definition is a straight quote from WP, matches the implementation, etc.

In fact you are mostly arguing about the behavior of a particular configuration of a particular implementation of CLOCK_REALTIME. But that?s not the same thing as ?Unix time?; it?s just one of several possible heuristics for dealing with leap seconds while returning a Unix time value.

No, it is not irrelevant. You claimed ?On linux it returns the same label as the previous second?. But this is only true if you use NTP (or some equivalent). If you don?t provide leap second information to the kernel then this behaviour will not occur. It?s perfectly possible to run a Linux system in which nothing supplies leap second information to the kernel and indeed this is true of many real systems.