The Unix timestamp will begin with 16 this Sunday

453 点作者 dezmou超过 4 年前

31 条评论

iso1210超过 4 年前

I remember staying up late (UK) at the Billenium (2:46 AM Sunday Sep 9th 2001), thinking that was bound to be the most newsworthy event of the week, watching the seconds tick past on a "while(sleep 1); do date" loop, with slashdot in one window, IRC in another, all running on an enlightenment window manager.500M seconds later I was in Washington DC in a hotel, watching it tick up on an rxvt on my laptop, with HN in a window.Who knows where I'll be in 2033, hopefully not in Europe as I'll be too old for night shifts, but wherever I am, I suspect it will have a bash prompt.

评论 #24454718 未加载

评论 #24455047 未加载

评论 #24455371 未加载

评论 #24460182 未加载

评论 #24457810 未加载

评论 #24454693 未加载

susam超过 4 年前

It is going to be at 2020-09-13 12:26:40 UTC.Python:<pre><code> $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) </code></pre> GNU date (Linux):<pre><code> $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 </code></pre> BSD date (macOS, FreeBSD, OpenBSD, etc.):<pre><code> $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 </code></pre> All such dates (in UTC) until the end of the current century:<pre><code> $ python3 -q >>> from datetime import datetime >>> for t in range(0, 4_200_000_000, 100_000_000): print(f'{t:13_d} - {datetime.utcfromtimestamp(t).strftime("%Y-%m-%d %H:%M:%S")}') ... 0 - 1970-01-01 00:00:00 100_000_000 - 1973-03-03 09:46:40 200_000_000 - 1976-05-03 19:33:20 300_000_000 - 1979-07-05 05:20:00 400_000_000 - 1982-09-04 15:06:40 500_000_000 - 1985-11-05 00:53:20 600_000_000 - 1989-01-05 10:40:00 700_000_000 - 1992-03-07 20:26:40 800_000_000 - 1995-05-09 06:13:20 900_000_000 - 1998-07-09 16:00:00 1_000_000_000 - 2001-09-09 01:46:40 1_100_000_000 - 2004-11-09 11:33:20 1_200_000_000 - 2008-01-10 21:20:00 1_300_000_000 - 2011-03-13 07:06:40 1_400_000_000 - 2014-05-13 16:53:20 1_500_000_000 - 2017-07-14 02:40:00 1_600_000_000 - 2020-09-13 12:26:40 1_700_000_000 - 2023-11-14 22:13:20 1_800_000_000 - 2027-01-15 08:00:00 1_900_000_000 - 2030-03-17 17:46:40 2_000_000_000 - 2033-05-18 03:33:20 2_100_000_000 - 2036-07-18 13:20:00 2_200_000_000 - 2039-09-18 23:06:40 2_300_000_000 - 2042-11-19 08:53:20 2_400_000_000 - 2046-01-19 18:40:00 2_500_000_000 - 2049-03-22 04:26:40 2_600_000_000 - 2052-05-22 14:13:20 2_700_000_000 - 2055-07-24 00:00:00 2_800_000_000 - 2058-09-23 09:46:40 2_900_000_000 - 2061-11-23 19:33:20 3_000_000_000 - 2065-01-24 05:20:00 3_100_000_000 - 2068-03-26 15:06:40 3_200_000_000 - 2071-05-28 00:53:20 3_300_000_000 - 2074-07-28 10:40:00 3_400_000_000 - 2077-09-27 20:26:40 3_500_000_000 - 2080-11-28 06:13:20 3_600_000_000 - 2084-01-29 16:00:00 3_700_000_000 - 2087-04-01 01:46:40 3_800_000_000 - 2090-06-01 11:33:20 3_900_000_000 - 2093-08-01 21:20:00 4_000_000_000 - 2096-10-02 07:06:40 4_100_000_000 - 2099-12-03 16:53:20</code></pre>

评论 #24458914 未加载

评论 #24453491 未加载

评论 #24454153 未加载

评论 #24454163 未加载

评论 #24454334 未加载

评论 #24454268 未加载

评论 #24458867 未加载

jezze超过 4 年前

When we one day become a space faring civilization we will probably stop using the gregorian calendar because why would you use that on say Mars?But there really is no reason to get rid of the unix timestamp as a measure of time and this measure may stay around for a long time. This may mean that people in the future might consider 1970 as year zero where modern civilization began.

评论 #24453612 未加载

评论 #24453644 未加载

评论 #24453969 未加载

评论 #24453550 未加载

评论 #24453810 未加载

评论 #24456705 未加载

评论 #24453502 未加载

fred256超过 4 年前

I hope you are running an up-to-date Splunk version:Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data.<a href="https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/FixDatetimexml2020" rel="nofollow">https://docs.splunk.com/Documentation/Splunk/latest/ReleaseN...</a>

评论 #24453773 未加载

NGC404超过 4 年前

All dates describing pattern:code:#!/bin/bashfor t in $(seq 0 100000000 $((2* * 31))); do date -u -d @$t +'%s -> %c'; doneoutput:0 -> Do 01 Jan 1970 00:00:00 UTC100000000 -> Sa 03 Mär 1973 09:46:40 UTC200000000 -> Mo 03 Mai 1976 19:33:20 UTC300000000 -> Do 05 Jul 1979 05:20:00 UTC400000000 -> Sa 04 Sep 1982 15:06:40 UTC500000000 -> Di 05 Nov 1985 00:53:20 UTC600000000 -> Do 05 Jan 1989 10:40:00 UTC700000000 -> Sa 07 Mär 1992 20:26:40 UTC800000000 -> Di 09 Mai 1995 06:13:20 UTC900000000 -> Do 09 Jul 1998 16:00:00 UTC1000000000 -> So 09 Sep 2001 01:46:40 UTC1100000000 -> Di 09 Nov 2004 11:33:20 UTC1200000000 -> Do 10 Jan 2008 21:20:00 UTC1300000000 -> So 13 Mär 2011 07:06:40 UTC1400000000 -> Di 13 Mai 2014 16:53:20 UTC1500000000 -> Fr 14 Jul 2017 02:40:00 UTC1600000000 -> So 13 Sep 2020 12:26:40 UTC1700000000 -> Di 14 Nov 2023 22:13:20 UTC1800000000 -> Fr 15 Jan 2027 08:00:00 UTC1900000000 -> So 17 Mär 2030 17:46:40 UTC2000000000 -> Mi 18 Mai 2033 03:33:20 UTC2100000000 -> Fr 18 Jul 2036 13:20:00 UTC--------------------------------------------------------------overflow of currently used datatype for timer happening at:code:#!/bin/bash date -u -d @2147483648 +'%s -> %c'output:2147483648 -> Di 19 Jan 2038 03:14:08 UTCinfo:<a href="https://en.wikipedia.org/wiki/Year_2038_problem" rel="nofollow">https://en.wikipedia.org/wiki/Year_2038_problem</a>--------------------------------------------------------------other interesting date:pi day:date -u -d @3141592653 +'%s -> %c'3141592653 -> So 21 Jul 2069 00:37:33 UTC (100th birthday for moonlanding mission on pi-day/sec)

评论 #24453594 未加载

roland35超过 4 年前

How exciting! 1500000000 occured on 07/14/2017 @ 2:40am (UTC), so it seems we'll have to only wait about 3 years until the next one!

评论 #24453039 未加载

评论 #24453576 未加载

browserface超过 4 年前

The crazy thing is there has only been 1.6 billion seconds since 1970. There have been more babies since 1970 than there have been seconds. Which is crazy.Back then, Earth's population was on 3.7 billion. Now it's 7.8 billion. That means that (ignoring deaths) 2.5 babies have been born for each unix second. Or roughly 1 baby every 400 milliseconds.

评论 #24453346 未加载

评论 #24453382 未加载

评论 #24455264 未加载

评论 #24453374 未加载

评论 #24453877 未加载

Retr0spectrum超过 4 年前

There's a nice countdown here: <a href="https://epochconverter.com/countdown" rel="nofollow">https://epochconverter.com/countdown</a>

评论 #24453155 未加载

评论 #24455195 未加载

codingdave超过 4 年前

I enjoyed the lunch party we threw at work when it hit 1234567890.I worked in Corporate IT at the time, so most of the office had no idea what we were celebrating. Somehow, neither did 80% of the tech staff. But the few of us who appreciated it really enjoyed the cake.

mocar超过 4 年前

And today is day 256 of 2020

评论 #24453901 未加载

fsckboy超过 4 年前

I'll be waiting to C-elebrate for 1,610,612,736* which is 122 days later or January 13th plus or minus a day or two (I was lazy).* 0x6000 0000

评论 #24459288 未加载

fanf2超过 4 年前

I have a twitter bot called time_t_emit that tweets palindromic seconds since the epoch. (somewhat inspired by the now defunct @megasecond)<a href="https://twitter.com/time_t_emit" rel="nofollow">https://twitter.com/time_t_emit</a>It's going to tweet twice tomorrow at lunch time (in my time zone) either side of the rollover.I fondly remember the gigasecond party I went to with a load of friends - it happened in the small hours on Sunday morning, ideal party time for a bunch of geeks in their 20s, like an extra new year's eve!

judge2020超过 4 年前

The exact time this happens is Sun, 13 Sep 2020 12:26:40 +0000 (you can paste 1600000000 in 'make another conversion')

评论 #24453110 未加载

评论 #24453032 未加载

评论 #24453452 未加载

numpad0超过 4 年前

`watch -n 1 date +%s`Wish I knew when 1234567890 happened, I was too dumb back then.

评论 #24453481 未加载

评论 #24453287 未加载

aljgz超过 4 年前

Gif recording of this <a href="https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif" rel="nofollow">https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif</a>

qwertox超过 4 年前

<a href="https://epochconverter.com" rel="nofollow">https://epochconverter.com</a> is the first bookmark in my bookmark bar, just the icon and no textI can only recommend using <a href="https://epochconverter.com" rel="nofollow">https://epochconverter.com</a> instead of Google's preferred result <a href="https://unixtimestamp.com" rel="nofollow">https://unixtimestamp.com</a> as it automatically detects if milliseconds are included, and it displays the local time more prominently.

willvarfar超过 4 年前

Tangentially related, last week I made a tiny one-file Java lib for working with Unix timestamps in milliseconds (as returned by System.currentTimeMillis() etc). It’s several orders of magnitude faster that Java’s time api!<a href="https://github.com/williame/TimeMillis" rel="nofollow">https://github.com/williame/TimeMillis</a>It’s probably not as fast as it could be: all speed ups and improvements welcome!

harikb超过 4 年前

Oh god! Don’t tell me I have to upgrade Splunk again!

compsciphd超过 4 年前

weird Q I was wondering about in regards to the epoch. (perhaps a stupid Q)what would be the problems with choosing a new epoch (i.e. one where jan 1 is the same day of week as jan 1, 1970 and is 2 years before a leap year. (perhaps doesn't exist).The worse case I see is that apps that calculate years internally (instead of via a shared library or like) would calculate them incorrectly. I'm wondering if this wouldn't be something that could be massaged around. Of course, it just pushes the problem down the road.it also makes timestamps like this incompatible between systems that have different epochs, which could be an issue.as I said, naive (possibly stupid) Q, just wondering if people have actually talked about it?

评论 #24463098 未加载

westurner超过 4 年前

It's gonna be so fun. In UTC:<pre><code> >>> import datetime >>> datetime.datetime.now().timestamp() 1599923432.252943 >>> datetime.datetime.fromtimestamp(16e8) datetime.datetime(2020, 9, 13, 8, 26, 40)</code></pre>

xwdv超过 4 年前

Any hackernews Zoom parties happening to commemorate the event?

评论 #24453765 未加载

eatbitseveryday超过 4 年前

Sorry for sounding ignorant, but why is this noteworthy?

tus88超过 4 年前

Avoir 15, you were my favorite time prefix so far :(

评论 #24459379 未加载

Donckele超过 4 年前

Thats Sunday, 13-Sep-20 12:26:40 UTC in RFC 2822

joshxyz超过 4 年前

What a ride fellas

ezekiel68超过 4 年前

From the, "I don't know who needs to desperately update their automated scripts..." dept. :rofl_emoticon:[0][0] Yes, I know this doesn't get transformed here.

zaroth超过 4 年前

Only the 9th time that’s ever happened!

rektide超过 4 年前

for my tribe counting in the best epoch this event commemorates the passing of 0x5F5E1000

评论 #24453898 未加载

sc_超过 4 年前

Crazy how nature do that

tester89超过 4 年前

Going from 1,5 Gs to 1,6 Gs

Andrew_nenakhov超过 4 年前

I make a bold prediction that we'll run out of digits rather soon.

评论 #24453104 未加载