Keeping 'order' without RTC.

When you're my age, the right day'll do, more or less.

Time to the minute is a luxury!

Seconds? Pah!

John

--
John Williams, now back in the UK - no attachments to these addresses! 
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject! 
 Click to see the full signature
Reply to
John Williams (News)
Loading thread data ...

The unix system clock ignores leap seconds. Each day since the epoch is counted as 24 * 3600 seconds.

Look at the value of the counter tonight at midnight UTC:

~$ date +%s -u -d 'May 5 2015 00:00:00'

1430784000

This is exactly 16560 * 24 * 3600. So leap second are not counted in the system clock's representation of "the number of seconds since the epoch".

Regards,

Kees.

--
Kees Theunissen.
Reply to
Kees Theunissen

Well, yes and no. If you have no way of telling your system that a leap second is to occur, then it cannot take account of it. If houser you have the leapsecond file or are running ntpd or chronyd then it does take leap seconds into account.

Which means that leap seconds HAVE been taken into account since there have been leap seconds since the epoch. The clock gives UTC. Of course this depends on what you call "takes account

Which means that leap seconds HAVE been taken into account since there have been leap seconds since the epoch. The clock gives UTC. Of course this depends on what you call "takes account". The number of seconds since the epoch is just what it would be if leap seconds were taken into account. That is not the same as the number of seconds that have actually elapsed since Jan1 1970.

Reply to
William Unruh

Unix time is the number of seconds that have elapsed since 00:00:00 UTC

1 January 1970. Leap seconds are ignored.
--
John Hasler  
jhasler@newsguy.com 
 Click to see the full signature
Reply to
John Hasler

Not sure what you mean by "leap seconds are ignored". AFAIK Unix time is UTC. UTC is does "ignore" leap seconds. Ie, they are not counted in the counting of the number of seconds between two dates. Is this what you are saying, or are you saying that Unix time is TAI?

Reply to
William Unruh

The definition of POSIX "seconds since epoche" and how to convert an UTC date to this representation can be found here:

[Xpost and Fup2 set to comp.os.linux.misc]
Reply to
Michael Baeuerle

He means exactly that. Count all the elapsed seconds since the epoch except for leap seconds. That?s the time_t value return by time().

I?m not sure what you mean by ?is does?. Traditional Unix time (or CLOCK_REALTIME) is just a counter, as described above. You can recover the corresponding UTC time (without knowing leap seconds) and the corresponding TAI time (but you need to know about all the leap seconds). You can?t go the other way: the moment half way through a leap second simply cannot be represented in Unix time.

--
http://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

Except for the difference in epoch, yes, Unix time essentially is TAI. It is a stream of sequentially numbered seconds. The UTC jiggery-pokery of skipping occasional seconds to try to approximate the irregular rotation of the Earth is ignored.

In practice no one actually uses Unix time as far as I know.

--
John Hasler  
jhasler@newsguy.com 
 Click to see the full signature
Reply to
John Hasler

Well, you and Kettlewell disagree. I also found the Wikipedia Unix_time, which they define as equivalent to Posix time,which says that Unix time is UTC seconds (ie leap seconds are not counted) except during the leapsecond itself when UTC adds in a 60th second to the hour, while Unix time jumps back at the end of that second.

Reply to
William Unruh

Every Unix and Linux machine, and an enormous amount of C & C++ code running on any platform, may beg to differ.

---druck

Reply to
druck

All using an offset version of UTC.

--
John Hasler  
jhasler@newsguy.com 
 Click to see the full signature
Reply to
John Hasler

That is what Linux time IS.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

Of course it doesn't. It's a simple device.

It may be set on shutdown, or it may be set more often. There is no "calibration".

The system doesn't know leap seconds either. It counts interrupts. There are demons that run on the system that monitor external time sources, like an NTP demon would. Windows (since at least NT and XP) have NTP clients built in, so in your terminology, yes, of course "Windows" takes leap seconnds into account. It may not do that for a week, but it will eventually do it.

If you are that interested in keeping up with leap seconds and are using Windows, then you will almost certainly be using a more frequent update interval for the Windows internal NTP client, or be using a third-party client.

Reply to
Mark Kramer

He said Unix time.

From Wikipedia Unix time (also known as POSIX time or erroneously as Epoch time) is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970,[1][note 1] not counting leap seconds.[1][2][note 2] It is used widely in Unix-like and many other operating systems and file formats. Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC.[note 3] Unix time may be checked on most Unix systems by typing date +%s on the command line.

And Note 3: Unix time cannot unambiguously represent UTC leap seconds (e.g. 31 December 1998 23:59:60), although otherwise the times it represents are UTC.

>
Reply to
William Unruh

So. Nothing in that disagrees with what I said.

there is a 1:1 correlation between Unix time and UTC.

Every single second of linux time corresponds to a single second in UTC.

Except where leap seconds are added, but that too is a formal defined and fixed relationship.

On a Linux or Unix system unix time is THE time the system has. Its

*interpreted* into UTC or other time by the local time functions, for human ease, but files are not marked with UTC.
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

Except for the representation of leap seconds. There is NO equivalent of

23:59:60 for example on Unix time. That is the time designation for a leap second in UTC.

So no there is not a 1:1 correlation.

Except leap seconds.

No, there is no designation of a leap second on Unix time. Unix time will never return the designation above. It simply stops the clock for that second making 23:59:59 two seconds long, not one.

Reply to
William Unruh

TNP is right to say that each second of Unix time corresponds to a single second in UTC; formally speaking, there is an injective mapping from Unix time to UTC. The reverse isn?t true, but I don?t think he (or anyone else) is claiming it is. As such ?Except leap seconds? make no sense as a response, because there is no representation of them among ?every second of Unix time?.

However, under current policies, future leap seconds are not fixed; the need for them is determined through measurement and their introduction is not predictable.

--
http://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

From the UNIX Programmer's Manual Volume 1 7th Edition, page 234:

*Time* returns the time in seconds since 00:00:00 GMT Jan. 1, 1970, measured in seconds.

Thus a stream of sequentially numbered seconds much like TAI. There could be no provision for leap seconds as they had not been invented in 1971 when the first edition came out.

What I meant by "nobody uses UNIX time" was that (almost) everybody has always just set the clock from the nearest UTC source.

--
John Hasler  
jhasler@newsguy.com 
 Click to see the full signature
Reply to
John Hasler

That depends on what you mean by "every second of Unix time". Unix time, UTC time, etc are all concerned with how the seconds are labeled. In Unix time, the leap seconds are either unlabeled, or in (almost) all implimentations they are labeled with the same label as the last second before the leap second. I do not believe tht any computer in existence would, if asked for the time on a leapsecond, return either and error, or an undefined. On linux it returns the same label as the previous second. On Android apparently, the time throught a timespan around the leapsecond returns a time which differs from UTC of Unix time by up to a second. I do not know what Posix says you should return if a time request comes in during a leapsecond.

Wikipedia claims that Unix time proceeds through the leapsecond, and then jumps back at the start of the next second. Thus the same Unix label refers to two different labels in either UTC or TAI.

Of course actually implimenting that would be a disaster, since, for example, a timestamp indicating a later time could have actually occured at an earlier time, confusing the hell out of the system. Thus Mills stops the clock and has the system clock return a slightly (by microseconds) later time on a subsequent call to the stopped clock. (Ie, the clock does not exactly stop, it ticks by a microsecond but only when actually queried.) That ensure that the clock always advances-- a later reading gives a later time. Pretty horrible if you are timing something, but...

Sure there is.

Reply to
William Unruh

The system clock does not stop "for that second". The system clock has no concept of leap seconds or when they are going to happen. If you have no time management other than the system clock, your system clock will be off by a second after a leap second occurs.

That's where NTP comes in.

Reply to
Mark Kramer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.