Talk:Unix time

	; Archives (Index) ;
	2012; 2013; 2014; 2015; 2016; 2017; 2018; 2019; 2020; 2021;
	This page is archived by ClueBot III.

Computing High‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
High	This article has been rated as High-importance on the project's importance scale.

Linux High‑importance

	Linux portal This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
High	This article has been rated as High-importance on the project's importance scale.

Time Mid‑importance

	This article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TimeWikipedia:WikiProject TimeTemplate:WikiProject TimeTime articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

This article has been mentioned by a media organization:

Feedback (New Scientist) (16 April 2005). "Feedback". New Scientist.

"1234567890" listed at Redirects for discussion[edit]

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

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

Team-B-Vital Improvement Drive[edit]

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

Need a clarification[edit]

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

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

Flat out wrong?[edit]

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

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

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

Archives (Index)
2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
This page is archived by ClueBot III.