Talk:Unix time

Archives (Index)

2012 2013 2014 2015 2016 2017 2018 2019 2020 2021

This page is archived by ClueBot III.

"1234567890" listed at Redirects for discussion

A discussion is taking place to address the redirect 1234567890. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 February 24#1234567890 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 23:00, 24 February 2021 (UTC)

It got relisted several times, and ended up at Wikipedia:Redirects for discussion/Log/2021 March 31#1234567890, and finally got closed as "make it a disambiguation page, because there's no consensus". Guy Harris (talk) 07:14, 30 May 2022 (UTC)

Team-B-Vital Improvement Drive

Hello all!

This article has been chosen as this fortnight's effort for WP:Discord's #team-b-vital channel, a collaborative effort to bring Vital articles up to a B class if possible, similar to WP:Articles for Improvement. This effort will run for up to a fortnight, ending early if the article is felt to be at B-class or impossible to further improve. Articles are chosen by a quick vote among interested chatters, with the goal of working together on interesting Vital articles that need improving.

Thank you!

Remagoxer ^(talk) 23:54, 15 October 2022 (UTC)

Need a clarification

Extracted from article:

Unix time is currently defined as the number of seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970, which is referred to as the Unix epoch. Unix time is typically encoded as a signed integer.^[1]

^[1] refers to "single-unix-spec-4.16"

↑↑ could someone refine here above and here below statement? ref. [1] - does not stipulate that Unix time is typically encoded as a signed integer. Instead it emphasizes: If the year is <1970 or the value is negative, the relationship is undefined. ... ↓↓

The Unix time 0 is exactly midnight UTC on 1 January 1970, with Unix time incrementing by 1 for every non-leap second after this.

Daniel exb (talk) 22:35, 30 August 2023 (UTC)

The Single UNIX Specifcation does not, as far as I can tell, require that the time be epresented as a signed integer, but it does allow it and, in practice, most if not all UN*Xes have time_t as a signed type. I've moved the reference after the first of the sentences you quoted, so it only applies to the definition of Unix time, not to the claim that it's typically encoded as a signed integer. Guy Harris (talk) 23:09, 30 August 2023 (UTC)

Flat out wrong?

This seems to be flat-out wrong: "without adjustments made due to leap seconds." It's then contradicted later, with "When a leap second occurs,...the Unix time number...experiences a discontinuity. Leap seconds may be positive or negative." So what's the deal with this? It seems we should delete "without adjustments made due to leap seconds.". ERCaGuy (talk) 18:02, 12 September 2023 (UTC)

Unix/POSIX time doesn't count leap seconds, in that the Unix time value for the beginning of a day is always exactly 86400 greater than the time value for the beginning of the previous day, even if the previous day ended with one or more positive or negative leap seconds.

This means that a time stamp value that increments by 1 every SI second is not a value that can be converted to Unix time without adjustments when a leap second occurs. Such a time stamp value can be converted to Coordinated Universal Time (UTC) (represented as a year/month/day date and an hours/minutes/seconds UTC value) with the aid of a table of all leap seconds that occurred or will occur prior to the date and time represented by that time stamp value (the code accompanying the tz database, for example, can do that).

"without adjustments made due to leap seconds" is a confusing phrase; what it means is that leap seconds aren't counted, as per Unix time § Leap seconds. Unix time § Definition says that "Unix time is currently defined as the number of non-leap seconds which have passed since ...", so perhaps "It measures time by the number of seconds that have elapsed since ... without adjustments made due to leap seconds." should be replaced by "It measures time by the number of non-leap seconds that have elapsed since ...". Guy Harris (talk) 02:49, 13 September 2023 (UTC)

I have made this edit Theanswertolifetheuniverseandeverything (talk) 12:01, 5 February 2024 (UTC)

Earth rotation and UTC leap seconds

"UTC includes leap seconds that adjust for the discrepancy between precise time, as measured by atomic clocks, and solar time, relating to the position of the earth in relation to the sun."

Unix timestamps have nothing to do with solar time, and it's not the *position* of the Earth in relation to the Sun but the *orientation* (or rotation). A leap second is when our clocks are stopped for a second to let the Earth catch up.

I find all this talk of the Unix timestamp counting seconds but not leap seconds very confusing. Unless I've misunderstood, the timestamp is the number of UTC *days* since 1970 Jan 1.0, multiplied by 86400.0. When a leap second is introduced, as far as Unix timekeeping is concerned the day is still 86400s long but the length of the second has changed for that day. The actual labeling of the successive seconds (57, 58, 59, 60, 00, and probably for the next one 57, 58, 00) doesn't seem to be addressed by Unix, and presumably the discontinuity is fudged out by subsequent NTP activity. PTWallace (talk) 07:55, 1 June 2024 (UTC)

Unix timestamps have nothing to do with solar time They don't, but a leap second, according to the "leap second" Wikipedia page, is "is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC), to accommodate the difference between precise time (International Atomic Time (TAI), as measured by atomic clocks) and imprecise observed solar time (UT1), which varies due to irregularities and long-term slowdown in the Earth's rotation", so Earth's rotation does complicate the relationship between "seconds since the Epoch" and "the number of SI seconds that have elapsed since the Epoch".

and it's not the *position* of the Earth in relation to the Sun but the *orientation* (or rotation). Yes, so the offending sentence needs to be corrected.

A leap second is when our clocks are stopped for a second to let the Earth catch up. Well, your clock may be stopped, but UTC clocks go from 23:59:59 to 23:59:60 to 00:00:00 the next day if a positive leap second occurs at the end of the day. That's nt stopping, that's just counting seconds in an unusual manner.

Unless I've misunderstood, the timestamp is the number of UTC *days* since 1970 Jan 1.0, multiplied by 86400.0. Such a time stamp would change once a day, not once a second, and that's not what happens in any system I know of, so you've misunderstood. (At least as I read the definition of "Seconds Since the Epoch" in 4.16 Seconds Since the Epoch, which says it's "A value that approximates the number of seconds that have elapsed since the Epoch.", if you are fairly liberal in what constitutes "approximating", a value that changes once a day would technically match that definition, but I think most people wouldn't consider "off by at most 86399 seconds" to be much of an "approximation".)

When a leap second is introduced, as far as Unix timekeeping is concerned the day is still 86400s long but the length of the second has changed for that day. That's one way to implement POSIX compliance; that's one form of leap second smearing. As that page says, there are other forms of leap second smearing, over periods of time other than one day. As far as I know, another way to implement it is to have the clock remain at 23:59:59 during the leap second.

The actual labeling of the successive seconds (57, 58, 59, 60, 00, and probably for the next one 57, 58, 00) doesn't seem to be addressed by Unix time_t has no notion of YYYY-MM-DD HH:MM:SS, even if shown as UTC; it's just a count of what would be the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC if every day since then were exactly 86400 seconds long.

However, POSIX includes gmtime(), which converts a time_t to a struct tm, which has fields for year, month, day, hour, minute and second. the gmtime page says that

The relationship between a time in seconds since the Epoch used as an argument to gmtime() and the tm structure (defined in the <time.h> header) is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch), where the names in the structure and in the expression correspond.

and the key bit of Seconds Since The Epoch is that tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 must be equal to the time_t value provided to gmtime().

It also says that

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. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

The Rationale (informative, not normative) says, in A.4.16 Seconds Since the Epoch:

The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time).

Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a system that provides the particular handling of external time in the way required by the application.

which sounds as if making the seconds of a day containing a leap second sufficiently longer than an SI second, so that exactly 86400 of those lengthened seconds occur during the day, is one possible way of making the day be 86400 seconds long, would be allowed, but nothing I see in POSIX would requires that particular way of handling leap seconds.

gmtime() is allowed to return a pointer to a struct tm containing a tm_sec equal to 60; C89, C90, C99, etc. allow that, and various versions of POSIX have picked the up from the C standard and not disallowed it. Unix systems that have the result of time() count seconds that have elapsed since the Epoch, including leap seconds, and that use the IANA tzdb files, compiled with leap-second support (the "right" rather than "POSIX" versions), will show "23:59:60" for the last second of a day with a leap second. This means that they aren't POSIX-compliant, but that they do have gmtime() display an approximation of UTC that more closely matches UTC the more precisely time()s seconds match the SI second. Guy Harris (talk) 11:46, 2 June 2024 (UTC)