View source for Talk:Unix time

{{WikiProject banner shell|class=C|vital=yes|1=
{{WikiProject Computing |importance=High}}
{{WikiProject Linux |importance=High}}
{{WikiProject Time |importance=Mid}}
}}
{{onlinesource
|author=Feedback (New Scientist)
|title=Feedback
|org=New Scientist
|date=16 April 2005
|url=http://www.newscientist.com/backpage.ns?id=mg18624953.100}}
{{User:ClueBot III/ArchiveThis|archiveprefix=Talk:Unix time/Archives/|format=Y|age=26297|index=yes|archivebox=yes|box-advert=yes}}

== Team-B-Vital Improvement Drive ==

Hello all! 

This article has been chosen as this fortnight's effort for [[WP:Discord]]'s [[Wikipedia:Discord/Team-B-Vital|#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! <!-- Substituted from [[Wikipedia:Discord/Team-B-Vital/Talk page notice]] -->

[[User:Remagoxer|'''<span style="color: #0a826b;">Rema</span><span style="color: #c91f0c;">goxer</span>''']] [[User talk:Remagoxer|<sup>(talk)</sup>]] 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{{nbsp}}UTC on Thursday, 1&nbsp;January 1970, which is referred to as the ''Unix [[epoch (computing)|epoch]]''. Unix time is typically encoded as a [[signed integer]].<sup>[1]</sup>

<sup>[1]</sup> refers to "single-unix-spec-4.16"
{|
|
 <span style="color: blue;">↑↑ 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. ...   ↓↓  </span>
|}

The Unix time {{val|0}} is exactly midnight UTC on 1&nbsp;January 1970, with Unix time incrementing by 1 for every non-leap second after this.

[[User:Daniel exb|Daniel exb]] ([[User talk: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 {{code|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. [[User:Guy Harris|Guy Harris]] ([[User talk: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.". [[User:ERCaGuy|ERCaGuy]] ([[User talk: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 {{section link|Unix time|Leap seconds}}.  {{section link|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 [[second]]s that have elapsed since ... without adjustments made due to leap seconds." should be replaced by "It measures time by the number of non-leap [[second]]s that have elapsed since ...". [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 02:49, 13 September 2023 (UTC)
::I have made this edit [[User:Theanswertolifetheuniverseandeverything|Theanswertolifetheuniverseandeverything]] ([[User talk: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. [[User:PTWallace|PTWallace]] ([[User talk:PTWallace|talk]]) 07:55, 1 June 2024 (UTC)
:{{tq|Unix timestamps have nothing to do with solar time}} They don't, but a leap second, according to [[leap second|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 clock]]s) and imprecise [[solar time#Mean solar time|observed solar time]] ([[UT1]]), which varies due to [[Earth rotation#Changes|irregularities]] and long-term [[ΔT (timekeeping)|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".
:{{tq|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.
:{{tq|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.
:{{tq|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 [https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 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".)
:{{tq|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 [https://developers.google.com/time/smear 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.
:{{tq|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}} {{code|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 {{code|gmtime()}}, which converts a {{code|time_t}} to a {{code|struct tm}}, which has fields for year, month, day, hour, minute and second. [https://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime.html the {{code|gmtime}} page] says that
:{{blockquote|The relationship between a time in seconds since the Epoch used as an argument to ''gmtime''() and the '''tm''' structure (defined in the ''[https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html <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 ''[https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 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 {{code|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 {{code|time_t}} value provided to {{code|gmtime()}}.
:It also says that
:{{blockquote|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 [https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 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.
:{{code|gmtime()}} is allowed to return a pointer to a {{code|struct tm}} containing a {{code|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 {{code|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 {{code|gmtime()}} display an approximation of UTC that more closely matches UTC the more precisely {{code|time()}}s seconds match the SI second. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 11:46, 2 June 2024 (UTC)