Jump to content

Talk:Unix time: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Mj1856 (talk | contribs)
133 edits
Mj1856 (talk | contribs)
133 edits
Line 106: Line 106:
: --[[User:LPfi|LPfi]] ([[User talk:LPfi|talk]]) 21:41, 20 June 2016 (UTC)
: --[[User:LPfi|LPfi]] ([[User talk:LPfi|talk]]) 21:41, 20 June 2016 (UTC)


== Terminology: Epoch Time ==
== Bad Terminology: Epoch Time ==


I've tried a simple edit in the past, but it was undone. Basically, there are a lot of people using the term "epoch time" on other sites and pointing here as proof that it is valid. The word "epoch" is a simple English noun, and Wikipedia describes it well in [[Epoch (reference date)]], which also has a list of other epochs used in computing. By inventing this term "epoch time", we've started a vocabulary of programmers saying things like "I have an epoch of 1499289809..." which is of course erroneous, as the epoch would always be 0 of any form of timestamp, and is explicitly 1970-01-01 00:00:00 UTC for Unix Time.
I've tried a simple edit in the past, but it was undone. Basically, there are a lot of people using the term "epoch time" on other sites and pointing here as proof that it is valid. The word "epoch" is a simple English noun, and Wikipedia describes it well in [[Epoch (reference date)]], which also has a list of other epochs used in computing. By inventing this term "epoch time", we've started a vocabulary of programmers saying things like "I have an epoch of 1499289809..." which is of course erroneous, as the epoch would always be 0 of any form of timestamp, and is explicitly 1970-01-01 00:00:00 UTC for Unix Time.

Revision as of 21:29, 5 July 2017


Archives (Index)

This page is archived by ClueBot III.

OEIS

OEIS: A215414 shows the Unix time at the start of each year, beginning with 1970. In this sequence, a(n+4)=a(n)+126230400 (not a(n)+126144000 due to an extra day every 4 years). GeoffreyT2000 (talk) 05:06, 11 February 2015 (UTC)[reply]

It ignores the Gregorian leap year rule. The term for the year 2101 should be 4133980800 rather than 4134067200. GeoffreyT2000 (talk) 05:23, 11 February 2015 (UTC)[reply]

Citation needed?

The 64-bit epoch will last for more than 290,000,000,000 years. 290 billion years ago there wasn't an earth. There won't be an earth 290 billion years from now. The end of 64-bit Unix time will not pose a problem. CarlosTakeshi (talk) 02:18, 18 March 2015 (UTC)[reply]

Other Calendars

It would be extremely useful for there to be a section about the Unix epoch in other calendars. There is a woeful lack of information on those, and I was unable to find much about them. I just don't want to be accused of like just putting a bunch of information on a page that's probably accessed a lot, so I thought I'd run it by here first. As you can tell, I'm kind of new to editing. The info I'd put is:

The UNIX Epoch in other calendars
Calendar Date Additional information
Julian 19-December-1969 Fell on a Thursday
Hebrew 5730-Teveth-23 Embolismic deficient (383 day year)
Islamic 1389-Shawwal-22 Fell on a yawm al-khamis
Persian 1348 Dey 11 Fell on a Panjshanbeh
Mayan 12.17.16.7.5 Lord of the night was G1
Chinese Yi-Chou (Ox), 24, 4667 Year Name was Ji You (Rooster)

Since these are all used for various purposes frequently (both UNIX time and the calendars), I think this would be relevant. The only problem is that it's really hard to find formatting info for a lot of these, since they're calendars and people are famous for not agreeing on calendars. Either way I'll post it if there are no complaints.

Jcbookman (talk) 23:23, 11 April 2015 (UTC)[reply]

Leap seconds?

I'm not sure I understand how "Ignoring leap seconds" is supposed to work. What happens during a leap second? Is unix time stopped and everything that happens during the leap second is attributed to the previous regular second instead? Or do the unix clocks just keep ticking until a check with a time server reveals that the clock is one second ahead and gets corrected then? Or does it work entirely differently? RedNifre (talk) 19:34, 13 April 2015 (UTC)[reply]

The time either continues as is or there seems to be a 1 second glitch in the clock if you have nntp. BTW: we discussed several times whether we should include leap second support in POSIX and up to now it turned out that you get more problems with leap second support than without it. Schily (talk) 09:20, 14 April 2015 (UTC)[reply]

No Mention of XKCD?

I think XKCD deserves some mention, since it is popular culture. Specifically http://xkcd.com/376/

If you ever go onto the /r/SoftwareGore subreddit, this comic is referenced all the time (no pun intended) And XKCD is one of the most popular web comics.

Since I'm still rather nooby to editing Wikipedia, I'm not adding this myself, but instead suggesting it here. Trainguyrom (talk) 15:33, 30 April 2015 (UTC)[reply]

We have something about that : WP:XKCD. Unless that comic had significant influence on the concept of Unix Time itself we shouldn't include it on this page. Xerxes (contact) 01:18, 19 July 2015 (UTC)[reply]

Please make the shortcomings clearer

The main article says some words about "not counting" leap seconds, but does not emphasize what inaccuracy and not-well-definedness results from this. From "forgetting" the leap seconds follows that

  • There is no well-defined "epoch". In 1975 the epoch was 1970-01-01 00:00:04 UTC; in 1980 the epoch was 1970-01-01 00:00:09 UTC, and so on. (So the sentence in the article saying "The Unix epoch is the time 00:00:00 UTC on 1 January 1970." is not true.)
  • For the question "what time is now (UTC)" the Unix time is (almost always) correct. But for questions like "what was the time (what year, month, day, hour, minute, second, UTC) 100000000 seconds before now", the Unix time is erronoeus. It incorrectly states that in that time the UTC ...hours and seconds were thisandthat. Similar is true for future dates.

Mhoeygii (talk) 02:18, 12 November 2015 (UTC)[reply]

Do you have any reliable sources to back up what you're saying? - Aoidh (talk) 23:17, 13 November 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to one external link on Unix time. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 19:53, 28 February 2016 (UTC)[reply]

The Wayback Machine link didn't work, but the article is still online, so I updated the link. (It's behind Rupert's paywall - which may account for why the Wayback Machine link didn't work.) Guy Harris (talk) 20:37, 28 February 2016 (UTC)[reply]

Does any system really keep a time a a pure linear count of seconds elapsed since 1970-01-01T00:00:00 *TAI*?

The Olson code (IANA tzdb reference implementation) can, if the leap seconds files are being used, convert a pure linear count of seconds elapsed since 1970-01-01T00:00:00 UTC to a UTC label such as 2015-06-30T23:59:60 UTC. It's not expecting a different-by-23-seconds pure linear count of seconds since 1970-01-01T00:00:00 TAI.

If a system were to keep a pure linear count of seconds since 1970-01-01T00:00:00 TAI, then a gmtime() implementation not taking leap seconds into account (such as the Olson code without the leap seconds files) would convert that to a TAI label. Guy Harris (talk) 19:51, 23 April 2016 (UTC)[reply]

Negative values of "seconds since the Epoch"?

I see nothing in the standard that clearly indicates that negative values of "seconds since the Epoch" are required; time_t is specified in the page on <sys/types.h> only to be "an integer type"; size_t is specified as being "an unsigned integer type" and ssize_t and some other types are specified as being "signed integer types", so this seems to indicate that the current Single UNIX Specification allows time_t to be signed or unsigned. Guy Harris (talk) 18:28, 20 June 2016 (UTC)[reply]

What is more, the source cited ("The Open Group Base Specifications Issue 7, section 4.15 Seconds Since the Epoch". The Open Group. Retrieved May 2, 2014.) says:
"If the year is <1970 or the value is negative, the relationship [between POSIX time and UTC] is undefined."
(The signedness is in this article explained to be for enabling representation of older dates, while the reason I have heard is to make calculating differences in time more straightforward.)
--LPfi (talk) 21:41, 20 June 2016 (UTC)[reply]

Bad Terminology: Epoch Time

I've tried a simple edit in the past, but it was undone. Basically, there are a lot of people using the term "epoch time" on other sites and pointing here as proof that it is valid. The word "epoch" is a simple English noun, and Wikipedia describes it well in Epoch (reference date), which also has a list of other epochs used in computing. By inventing this term "epoch time", we've started a vocabulary of programmers saying things like "I have an epoch of 1499289809..." which is of course erroneous, as the epoch would always be 0 of any form of timestamp, and is explicitly 1970-01-01 00:00:00 UTC for Unix Time.

Can we please remove the "epoch time" terminology and add a paragraph explaining that this usage is erroneous and should be avoided? We can leave the redirect in place so people find it. Thanks.

mj1856 (talk) 21:26, 5 July 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Unix_time&oldid=789183668"