Talk:Unix time

Epoch fail

I tried to make the box show the cool epoch, but was out by a second :( Someone then overwrote it anyway. Sorry guys.91.107.35.245 (talk) 23:43, 13 February 2009 (UTC)

Sign bit ??

I do not believe the 32-bit time_t uses a sign bit. I believe the integer is encoded with twos-compliment. This means there is not a dedicated sign bit. It also means that the range is -2^32 .. 2^32-1 instead of 1-2^32 .. 2^32-1.

68.157.195.202 (talk) 16:31, 5 May 2008 (UTC)

Better Description

From what I've read, this is how I understand it: The second for UT time is variable. The second for TAI time is invariable. In order to use the TAI second and match times with the sun's light (UT), we need to maintain an offset from the TAI reading. This coordination between TAI and UT is UTC. The offset is calculated by accumulating leap seconds. Since humans are interested in connecting time to the sun, and computers are interested in keeping time with seconds of unchanging length, personal computers use UTC; thus, a unix timestamp is simply the number of seconds between 2 dates:

       (1) The Epoch: 00:00:00 UTC, January 1, 1970
       (2) Current Time: The date displayed by a computer

In this sense, the unix timestamp is indeed just an encoding of UTC; it is an offset (timestamp) from an origin (the Epoch); also, leap seconds are unimportant to the discussion of Unix Time, because the current time of the computer has already taken them into account; leap seconds are only interesting to a discussion of UTC.

It's probably more correct to say that Unix time is an encoding of TAI time plus an offset to align it with UTC time. Like TAI time, Unix time does not include leap seconds. But like UTC time, Unix time is aligned to the current worldwide time standard, which is based on UTC. So Unix time is a (convenient?) combination of the two time scales. — Loadmaster 21:58, 17 February 2007 (UTC)

In 7 UTC days, I will update this entire article to reflect concisely these ideas.

--Lingwitt 06:38, 20 January 2007 (UTC)

Given that nobody has responded to this, I will wait another 7 UTC days --Lingwitt 10:28, 27 January 2007 (UTC)

Unfortunately, I don't have TIME to do this. Hopefully I will later. --Lingwitt 02:40, 4 February 2007 (UTC)

knowledge of leap seconds

How does the unix-time-function know that at the end of a given year, a leap second will be inserted?

I mean, leap seconds are announced maybe a year before they accour. So how does a unix-time-function programmed in the 80s know, that there will be a leap second within 1998-12-31T23:59:60.00Z?

Seeing this problem, and assuming that unix time should be absolute at any program generating unix time, i would guess that Unix time is not fixed to the leap second (and thus is more like the mentioned TAI timecode).

--Abdull 10:44, 2 Mar 2005 (UTC)

Leap second warnings are transmitted in the Network Time Protocol. That's how most Unix machines know when to diddle the time value. Machines not on NTP, which don't know about leap seconds and so don't diddle the time, end up wrong after the leap second and need to be changed -- but if they're not on NTP then the clock's probably more than a second wrong anyway. 195.224.75.71 09:36, 7 October 2005 (UTC)

The UNIX kernel always counts seconds monotonically, it does not know about seconds, leap seconds, or even leap years. Just the number of seconds since 1970 (GMT). When an outside time base (such as NTP) notifies the kernel, two things can happen: 1) on older kernels, it just sees a "new time from NTP that is different from what it has" and steps the clock to the new time. When this happens depends on the NTP polling interval; 2) on newer kernels that have leap second support, it counts the second as it happens thanks to notification from the client NTP daemon. --M s brown 19:56, 30 November 2005 (UTC)

A side effect of NTP "correcting" UNIX time is that it changes the Epoch of UNIX time by a second, so it is no longer at 00:00.00, but the accumulated leap-seconds since 1970 make it several seconds later. 84.167.5.200 20:31, 25 December 2005 (UTC)

In the current edition of 1003.1-2004 (as available online from The Open Group) I can't find any information on how leap seconds are mapped to time_t. In particular, (as far as I interpret it) the IEEE standard does not support the examples given on Wikipedia about time_t jumping back during the positive leap second and jumping forth one second during a negative leap second. In fact, 1003.1-2004 says: How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. Shouldn't the examples given at least marked as implementation-dependent examples? -- Harald 14:36, 28 March 2006 (UTC)

epoch

What timezone is the first epoch started in? Thursday january 1st 1970, but what timezone?

-- Anders

leap seconds have never been announced more than 181 days ahead. UNIX time was (effectively) started in the GMT (Z) time zone, because that's the basis for UTC.

The claim about "On 2009-Feb-13 23:31:30 UTC, . etc" can't be certain because leap seconds could be put in, though none has for several years. So I added a proviso. Pdn 13:13, 22 Apr 2005 (UTC)

Why time_t is signed

The article indicates that time_t is signed in order to represent dates earlier than 1970. This does not agree with my understanding of the design decision; time_t is only intended to represent dates/times relevant to the operating system, not for representing dates and times in general. That is, time_t is meant for things like file modification times, the time the machine booted, and the system clock. Programmers who use a time_t to record, say, a person's birthdate are misusing the type, and should use something like a struct tm. Since all times relevant to the OS are later than 1970, it is not important that time_t be able to record times earlier than that. However, the decision was made in antiquity that time(3), whose return value is time_t, should return a negative value in case of error. This decision having been made, time_t must be kept as a signed type. Can anybody with a more thorough knowledge of UNIX and POSIX history confirm or dispute my understanding? -- Coneslayer 16:39, 2005 Jun 21 (UTC)

On the contrary, Unix time_t *is* general-purpose. Early on it wasn't used for anything except current time and file timestamps, which is why there was this uncertainty. I recall that Dennis Ritchie, when asked about the signedness of time_t, said he hadn't thought very deeply about it, but was of the opinion that the ability to represent all times within his lifetime would be nice. Dennis's birth time is around Unix time -893400000. 195.224.75.71 09:36, 7 October 2005 (UTC)

We've discussed in the POSIX WG, making time_t unsigned whenever the 2038 issue has come up. The problem is that historical usage of time() with its "-1" return code for error, make this change unacceptable for many due to the amount of currently functioning code that would break. --M s brown 20:00, 30 November 2005 (UTC)

Hopefully by the time 2³¹-1=Tue Jan 19 03:14:07 2038 UTC occurs, everyone will be using 64 bit time_t anyway, and it won't matter much. The conversion is already beginning. --ssd 06:40, 20 January 2006 (UTC)

Since on almost all systems "time_t" is a alias for "long", the "conversion" is indeed automagic due the migration to 64-bit systems on which "long" is normally a 64-bit integer. For example, Alpha machines have been Y2038-ready for about a decade. An unsigned integer would be particularly fatal for the huge amount of programs which calculate with time_t like t1 - t0 and expect negative values too. This can be considered buggy but there's far are too much code doing exactly this. Thus a "fix" like that could easily cause more problems than it solves. Also (time_t)-1 is a "bump" in timespace as it's considered an error indicator by many functions e.g. mktime. --82.141.57.229 11:08, 26 June 2006 (UTC)

"Almost all systems" is a relative term. Most of the 32-bit and 64-bit Unixes I've used equate time_t to a 32-bit signed integer. It's also a fact that almost all external file formats with an embedded binary time_t value use a 32-bit wide integer. - Loadmaster 21:20, 9 August 2006 (UTC)

One of the benefits of making time_t a signed type is the ability to derive a signed difference between two time values. For example, dif = t1 - t2 yields a negative value if t1 comes before t2. If time_t were unsigned, the resulting dif value would be a huge unsigned value. - Loadmaster 21:20, 9 August 2006 (UTC)

It should also be noted that some systems properly handle negative time_t values, as dates prior to 1970-01-01. - Loadmaster 21:20, 9 August 2006 (UTC)

NTP vs POSIX

I've put the material on the NTP variation of Unix time into a separate subsection. Please don't mix it up with the main discussion again. The NTP-based version *is not* POSIX time. 195.224.75.71 09:36, 7 October 2005 (UTC)

TAI-variant epoch

The article mentions "Because TAI has no leap seconds, and every TAI day is exactly 86 400 s long, this encoding is actually a pure linear count of seconds elapsed since 1970-01-01T00:00:00 TAI." I know Olson's timezone database uses 1970-01-01 00:00:10 TAI as the epoch. Is this a typo or reference to something else? --anonymous

It's something else, as far as I know. That epoch was probably chosen for that purpose because when UTC started using the leap second mechanism, in 1972, it was set to 10 s behind TAI. (As of January 2006, we've had a total of 23 leap seconds, and UTC is now 33 s behind TAI.) In the first half of 1972, the period before the first leap second, the Unix time number (as we now define it) was equal to a linear count of seconds since that epoch. This epoch is probably chosen so that a table of leap seconds (the first being on 1972-06-30) can be used to relate the Unix time number to this linear count in the obvious way, without having to allow for the initial 10 s TAI-UTC difference in any more complicated manner. 195.224.75.71 15:30, 11 January 2006 (UTC)

How to get unix time in code

I was wondering what people thought of the idea of having a section for ways to access the unix time using some of the more popular programming languages. The number of languages would have to be limited because it could easily get out of hand - a huge list of functions hardly seems relevant to the time - but since this is UNIX time we're talking about, something designed for computers, I think it would be useful to know how computers access it. Any objections? -- Drrngrvy 20:36, 19 January 2006 (UTC)

I presume you're talking like:

Language	Function
C	gettimeofday(2)
PHP	mktime()

<?> Cburnett 23:41, 28 March 2006 (UTC)

• That's exactly what I'm talking about, perhaps with a mention of the header/library the function exists in (late reply I know). - Drrngrvy 18:30, 25 April 2006 (UTC)

I added a new article, time (computing), and added your table to it. — Loadmaster 17:29, 22 August 2006 (UTC)

So what's the correct way

of measuring elapsed time on recent variants of *nix (in particular linux and *bsd)? Plugwash 00:04, 26 April 2006 (UTC)

A colleague of mine tells me that Linux does not introduce non-monotonicity as a result of leap seconds. (See comment near the top of second_overflow() in kernel/timer.c.) It avoids the problem by slewing the clock following a known leap second. 128.197.24.164 (talk) 01:34, 22 March 2008 (UTC)

POSIX timescale functionality

In the "History" section, the article mentions that POSIX added some functions in 2004 to allow programmers to get the time in different time scales. Does anyone have a reference for this? Which functions were added (I can't see anything obvious in SUSV3 2004 edition, but perhaps I'm just missing it as I look through)? — Ajhoughton 15:44, 22 August 2006 (UTC)

Perhaps this was talking about the REALTIME (POSIX.4) functions, e.g. clock_gettime()? Anyone? — Ajhoughton 16:01, 26 August 2006 (UTC)

I agree with you this is not clear enough. If it refers to the clock_gettime() and similar material, this is nothing new to 2004, it existed much before, as you said it came with the realtime extensions (1003.1d-1999 ?).

Since nobody answers your comment for more than 1 year, I added a { {fact} } tag along the dubious assertion, in the hope someone will improve the documentation of that point.AntoineL (talk) 10:49, 9 January 2008 (UTC)

UTC

POSIX time is not UTC time, because it completely ignored leap seconds and assumes that every day is exactly 24×60×60 seconds long. It's probably more correct to say that it is a variant of TAI time. — Loadmaster 17:25, 22 August 2006 (UTC)

POSIX time is not a variant of TAI time, for the exact same reason. There are as many seconds between any two given points in both TAI and UTC (since the two have their seconds synchronised, this should be of no surprise). However, POSIX time may have one fewer second if the interval between the two points straddles a leap second.

The annoying part is that it is impossible to unambiguously convert POSIX or NTP time to a linear, deterministic time scale because of the missing seconds. That is, given the timestamp 915,148,799 or 915,148,800, it is impossible to tell whether it represents 1998-12-31 23:59:60 or a time one second either side of that value. —Ajhoughton 15:59, 26 August 2006 (UTC)

---

The way I read it, POSIX time does not corrispond with UTC. It trivially maps onto the older GMT in which a day was defined to be exactly 24 * 60 * 60 seconds. 12.117.131.6 (talk) 22:16, 9 May 2008 (UTC)JH

Some issues with the UTC basis of Unix/POSIX time_t are evident in the javascript of this web page http://www.ucolick.org/~sla/leapsecs/epochtime.html In particular, this highlights the distinction between current time and elapsed time and the impossibility of an unambiguous interpretation. The French version of this page has incorporated some of those issues. Does it help to point them out here in English too? Steven L Allen (talk) 17:58, 21 April 2009 (UTC)

60 Hz clock?

"The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which was the rate of the system clock on the hardware of the early Unix systems".

The PDP-7 had a ~1-2 Mhz CPU, so can someone clarify what the 60 Hz is referring to? The interrupt speed?

Answered this myself. Yes, effectively an interrupt, divided down from the CPU cycle speed.

Why 1970?

Okay techies, I came here to find out why they picked this particular date, but to no avail. So please add this information to the article. It's not easy to find the answer on the web and actually I still don't know why this date was picked. —Preceding unsigned comment added by 129.15.165.76 (talk) 22:20, 30 April 2008 (UTC)

The first Unix systems were being developed in the very early 1970s, and the developers just chose the beginning of the current decade (which had just begun). If Unix had originated in the early 1960s or the early 1980s, they probably would have used the start of that decade instead. Next time, you would probably get a faster response if you asked this kind of question on the computing reference desk. --arkuat (talk) 07:18, 3 June 2008 (UTC)

"Non-linear?"

Maybe I'm missing something, but doesn't Unix time measure the number of physical seconds from the epoch, meaning that a person counting seconds from the epoch would have an accurate Unix timestamp? That seems absolutely linear to me.

Also, the point about Unix time always counting a day as 86400 seconds seems odd: Unix time measures only seconds, not days. A day can be, as the article says, of varying lengths, so the software that interprets Unix time needs to account for known leap seconds. —Preceding unsigned comment added by Kinghajj (talk • contribs) 04:51, 14 August 2008 (UTC)

I think you're confusing Unix time with the International Atomic Time-based variant, which measures actual seconds, and so needs a table of leap seconds for exact conversions to UTC (but not for exact computation of time spans). Unix time skips leap seconds, which means that a table of leap seconds is needed for exact computation of time spans, but not for exact conversions to UTC. -- Jao (talk) 13:32, 3 November 2008 (UTC)

Example

I fixed the example. It was making it much harder than it needed to be. Superm401 - Talk 03:02, 14 November 2008 (UTC)

date -d example

Here's another example you might employ. Jidanni (talk) 03:39, 12 December 2008 (UTC)

$ for t in -1 0 +1; do date -ud "0:00 jan 1 1999 UTC $t sec"; done
Thu Dec 31 23:59:59 UTC 1998
Fri Jan  1 00:00:00 UTC 1999
Fri Jan  1 00:00:01 UTC 1999

TIME_OOP?

Anyone know what "TIME_OOP" stands for? --24.5.77.60 (talk) 19:44, 1 January 2009 (UTC)

the time since 00:00:00, Jan. 1, 1971?

the history section says "the time since 00:00:00, Jan. 1, 1971". what does this have to do with 1970? --24.190.217.35 (talk) 09:06, 10 January 2009 (UTC)

You mean when was the epoch changed to 1970? According to this post, 1970 was first used in Fourth Edition Unix, which was released in November 1973. Apparently also, 1972 was briefly used as the epoch in between. -- Jao (talk) 12:23, 10 January 2009 (UTC)

It's still too early to try and build a consensus concerning what to change the epoch to in order to continue using 32-bit time_t past 2038, right? FWIW, I like 00:00:00 Jan 1, 2030, which, as that will still be in the future for a while, mandates a correct handling of negative time_t. —Preceding unsigned comment added by 75.87.135.149 (talk) 17:27, 23 June 2010 (UTC)

Countdown to hexadecimal 50000000 seconds

Gentlemen, stand back, it's... another countdown for you:

$perl -lwe 'print scalar gmtime 0x50000000;'
Fri Jul 13 11:01:20 2012

Jidanni (talk) 19:14, 12 February 2009 (UTC)

Second Example

Is there a reason that the second example was added? It seems a little redundant and just shows the time for 1234567890. Having only one example using the time from the last generation seems like plenty to me. --Coban (talk) 12:52, 13 February 2009 (UTC)

NOOOOOOOOOOOOOOOOOOOOOOOOOO, why did someone have to purge it, it needed to be last created on the epoch time. 1234567890 :(Scientus (talk) 23:46, 13 February 2009 (UTC)

Description of issues with Daylight Savings Time

I'd like to see more info on time_t and DST... the main page says that times "increases by exactly 86400 (24*60*60) per day since the epoch", but that's not true - some days it increases by 23*60*60 seconds, and on some days it increases by 25*60*60 seconds. In my mind this is a far bigger problem than the "leap seconds" that everyone seems so concerned about. —Preceding unsigned comment added by 12.200.68.178 (talk) 18:21, 16 September 2009 (UTC)

That would be because time_t is kept in UTC (with the caveats listed in the article) and UTC doesn't have summer/winter time. Summer/winter time is applied when time_t is converted to local time for display. --60.241.25.199 (talk) 08:24, 26 October 2009 (UTC)

How to find the time since the Epoch on Unix at the shell

Does anyone know of a portable way of finding the time since the epoch on a unix machine? Even ignoring leap seconds, it seems a difficult task.

date -u "+%s" works on GNU date. but is non-standard. It does not work with the date command on Solaris or HP-UX.

awk 'BEGIN {srand(); printf("%d\n", srand())}' works for most versions of awk. Apparently POSIX states the random number generator must be seeded by the time, but does not say what time. Most awks use seconds since the epoch, but I believe that is not so on OpenBSD.

Perl, python and others languages have their own options, but it's hardly appropriate to assume such tools exist. —Preceding unsigned comment added by Drkirkby (talk • contribs) 13:47, 12 October 2009 (UTC)

The tables in the system time article might help. Some programming languages use a specific epoch. — Loadmaster (talk) 18:47, 26 October 2009 (UTC)

Question

Since the live time examples aren't used on the Swatch Internet Time and New Earth Time articles should it be removed from this article too? —Ғяіᴆaз'§Đøøм • Champagne? • 8:47pm • 10:47, 27 September 2010 (UTC)

celebrations of special numbers of seconds in Unix time

Mention of these (if any) belong in trivia, not near the start of the article.