Talk:Unix time

From Wikipedia, the free encyclopedia

You have new messages (last change).
News This page has been cited as a source by a media organization. See the 2005 press source article for details.

The citation is in: Feedback (New Scientist). "Feedback", New Scientist, Issue Dated 16 April 2005.

Contents

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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 231-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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] so whats the correct way

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

[edit] 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)

[edit] 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)
Retrieved from "http://en.wikipedia.org../../../u/n/i/Talk%7EUnix_time_3c78.html"