Ah yes, leap seconds are a mess in Unix. How could I forget.

I think your timestamp observations are perfectly explicable BDD, in that the filesystem has one epoch (inherited from DOS) and the OS has another epoch.

Leap seconds are a mess in general. We would have been better of without them.

It's possible to avoid leap seconds in practice by adopting UT1 instead of UTC. Most people won't notice, because the two are defined to be within 1 second of each other (UTC has leap seconds to maintain this relation while also adhering rigidly to the SI second). GPS signals include specifying the offset to the nearest tenth of a second.

I prefer my seconds to be of constant length!

In that case, you have to occasionally accept (and deal with) minutes containing 61 or 59 seconds.

There are alternative proposals, one being to wait until 30 mins of drift and then take a leap hour.

Yeah, people are arguing whether to abolish DST and whether to switch to winter or summer time. That's an hour, and nobody's getting terribly upset. Letting the leap seconds add up to something we actually care about would save a lot of grief.

On the topic of epochs, most of the applications I make don't have a real-time clock, so epoch starts when device is turned on, and everything else is relative.

I've also used beginning of year 2000. Unless you're using standard libraries, or transferring the binary value across domains, you can choose your own.

I think I'll use my birthday next time I need to define an epoch

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm not sure, but it seems possible the BBC Micro could lose time when there's heavy disk or network I/O, because time is dealt with by IRQ and those two fast subsystems are dealt with by NMI. But, with the 100MHz jiffy clock, you'd need to miss not just one tick, but the next tick too, 10ms later.

The later BBC Master has a RTC as well as the time-since boot.

But, when benchmarking a program, it's simpler to set TIME to zero than to store it to subtract later. So, not always time-since-boot - sometimes time-since-benchmark!

I don't generally include time as part of many of my embedded systems: it just isn't needed. However, when it is, I try to include a short counter that counts unserviced jiffy time interrupts. The ISR can then keep time correctly even when activities on the processor prevent it from servicing all jiffy time interrupts. Generally, this additional complexity is unnecessary for interrupt rates on the order of 20-100 times per second. However, with rates on the order of 200-1000+ times per second, it is easy to have processes require more time to complete than the interval between interrupts.

_________________
Michael A.

That could get very ugly!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Norsk Data used 1/1 1950 as epoch. Unfortunately it was also encoded as year/month/day/hour/min/sec, like MS-DOS, just with slightly different sized bit fields. That lead to myself having to stay at work during the days crossing from end of December to beginning of January, because the software that we used, which was written by another company, inadvertently managed to introduce bugs in their time calculations. Which tended to pop up now and then, depending on leap years and more. And, as the software was literally life-important, it was necessary to catch it in realtime.
Since then (the early eighties) I've always advocated for doing all time calculations in seconds (or ticks or whatever), never on the individual months/days/hours.
And yes, the real-time clock of any computing device should be in ticks, or seconds, or nanoseconds, or Planck time, linearly increasing. Unix time isn't bad, except that it should have based on UT1 seconds, not UTC. And I think there are patches for Linux to do that. It's a very bad thing to modify the actual clock counter on the system, ever. Shouldn't be done for leap seconds either, that should be translated when displayed, just as everything else is handled via the timezone transformation.

I'm not sure if it's a consensus, but instead of leap seconds some big players now apply a leap smear - but, not all of them the same, at present. See https://developers.google.com/time/smear

There are almost always bugs in time-handling. Best to use something already well-used. At least with something like a complex day-of-week calculation it should be very practical to test a half-million cases, which is a 1400 year range, more or less. So long as your test logic matches the calendar!