Talk:Unix time/Archives/2012

This is an archive of past discussions about Unix time. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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

You're having trouble understanding what it means. It would be regardless of a time zone. You see, here's an example-

Say it's 1:02 A.M. In Boston. The same time prompt may appear at a different time in Alaska, but at the same time it's a different time prompt. Nevertheless, at one time they'll both get to 1:02 A.M., and then they can certainly say, "Boy, two minutes ago it was 1:00!" but not the two of them would say it at the exact same time.

Okay, maybe that was a bad example, but what I'm trying to say is, it's not 1,000,000 here if it's 1,000,000 there, because they have different time zones. Unix time is as international as time zones....which really....uh....isn't that international.

P.S. SIGN YOUR POSTS!!!!!

--John Smith 18:43, 7 January 2012 (UTC)

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)

In fact, as the article states, the Epoch is "midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970" - i.e., the article explicitly states that the Epoch is defined in terms of UTC. Guy Harris (talk) 19:36, 7 January 2012 (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)

Is there a citation for this? The table over at Epoch_(reference_date)#Notable_epoch_dates_in_computing would like to know. --Kvng (talk) 15:11, 1 September 2011 (UTC)

So Win-DOS is from 1601? --Schily (talk) 21:44, 1 September 2011 (UTC)

No, DOS is from 1980, where its time starts. Windows NT, which isn't DOS-based and which introduced FILETIME, with the 1601-based origin, is from the late 1980's. And VMS, which has an epoch from the late 19th century, is from the late 1970's. So the developers of an OS can pick an arbitrary epoch; the question is whether the Unix developers picked the beginning of 1970 because it was the current decade, or for some other reason. No citation has been given, as far as I know, for the second part of Arkuat's claim (the first part, "The first Unix systems were being developed in the very early 1970s", might be true, although the work on it started in 1969). Guy Harris (talk) 01:04, 2 September 2011 (UTC)

Well, I was joking.... but as MS repeatedly mentiones DOS in their libc for WNT (source comes together with MSC), it may be adequate to call it Win-DOS ;-) Using 1601 as the Epoche is an extremely unwise decision, as this does not refer to a unique date due to the distrust on the catholic church in the time past the Reformation. January 1st 1601 in Berlin is not the same day as January 1st 1601 in Paris.

Yes, UNIX recently turned 42!!! but it used a 60Hz based time value in it's first years that forced a new epoche for every year. The current time_t base was introduced with UNIX v6. --Schily (talk) 16:23, 2 September 2011 (UTC)

Perhaps Microsoft are using the proleptic Gregorian calendar, which doesn't have that problem.

Was it V6 that introduced that time_t base, or was it introduced earlier, but V6 was just the first release whose source was made broadly publicly available (I think some people at Harvard's Science Center, I think, having had access to V5)? Guy Harris (talk) 17:11, 2 September 2011 (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)

Although exact conversion from UTC to POSIX time is impossible for any UTC time that ends in ":61", i.e. for any UTC time during a positive leap second. Some mechanism informing the machine of leap seconds, such as a table of leap seconds or an external leap second announcement (such as NTP delivers) is necessary to allow an otherwise counter-based clock to provide POSIX time, as it has to know when to stop or move back the counter (for a positive leap second) or whether to jump it ahead an extra second (for a negative leap second). Guy Harris (talk) 23:26, 26 November 2012 (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)

Is it still too early to determine whether anybody's going to even bother changing the epoch in order to continue using 32-bit time_t past 2038, rather than just switching to 64-bit time stamps in OS APIs and file formats? Guy Harris (talk) 23:31, 26 November 2012 (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. —Preceding unsigned comment added by 81.140.57.113 (talk) 12:24, 15 December 2010 (UTC)

I agree. I have removed these from the lead. I also would like to suggest that the Unix_time#Notable_events_in_Unix_time needs a trim. --Kvng (talk) 18:17, 8 November 2011 (UTC)

I have added a time limit for 32 bit unsigned numbers (February 2106). Even though Unix time is held by a signed 32 bit number, some unix-like systems or embedded applications use unsigned numbers for the UTC time, and people using these systems may want to know where the limit is. — Preceding unsigned comment added by 66.84.205.171 (talk) 21:15, 23 November 2011 (UTC)

Scalar real number

The first layer encodes a point in time as a scalar real number...

There are real numbers which aren't scalars? Marnanel (talk) 22:36, 22 February 2011 (UTC)

Dead link?

In External links, the link with link text "Convert a UNIX timestamp to a readable format" may no longer be working (web browser reports "Connection closed by remote server"). It did not work at the time of posting this (although it could be traceroute'd) --Mortense (talk) 14:41, 11 March 2012 (UTC)

I just tried it and had no problem converting three different numbers to dates. --Guy Macon (talk) 15:40, 11 March 2012 (UTC)

It seems to have been a short outage. It is also working for me at the time of posting this. --Mortense (talk) 15:56, 11 March 2012 (UTC)

Representing the number

In the "Representing the number" section, should it be mentioned that many file formats store (Unix) timestamps using only four bytes (32 bits)? Expanding the width of the time_t solves the Year 2038 problem for date/times executing in memory, but does not solve the farther reaching problem of date/times stored within files. — Loadmaster (talk) 17:49, 26 March 2012 (UTC)

I think that would be a nice addition to the article. It would have to be sourced, of course. --Guy Macon (talk) 02:06, 27 March 2012 (UTC)