Readit News logoReadit News
SPHINXc-- · 2 years ago
Actually a cool date pivot point. Did not realize it was coming up (and has now passed). Thanks.
ChrisArchitect · 2 years ago
dang · 2 years ago
Thanks! Macroexpanded:

The Unix timestamp will begin with 17 this Tuesday - https://news.ycombinator.com/item?id=38222909 - Nov 2023 (75 comments)

Let's restart counting Unix timestamp to from 2020 - https://news.ycombinator.com/item?id=35202256 - March 2023 (21 comments)

Tomorrow the Unix timestamp will get to 1,666,666,666 - https://news.ycombinator.com/item?id=33316429 - Oct 2022 (116 comments)

Happy 1600M epoch second - https://news.ycombinator.com/item?id=24460382 - Sept 2020 (48 comments)

The Unix timestamp will begin with 16 this Sunday - https://news.ycombinator.com/item?id=24452885 - Sept 2020 (203 comments)

Unix Time 1500M – Friday July 14 02:40UTC - https://news.ycombinator.com/item?id=14758615 - July 2017 (99 comments)

Today at 16:53:20 GMT, it'll be 1400000000 in Unix time. - https://news.ycombinator.com/item?id=7736739 - May 2014 (57 comments)

Ask HN: What will you be doing when the unix timestamp reaches 1234567890, next friday? - https://news.ycombinator.com/item?id=475437 - Feb 2009 (3 comments)

hmaxwell · 2 years ago
next one is in 3 years
SamBam · 2 years ago
Set a calendar notification for Friday, January 15, 2027 8:00:00 AM GMT.

Woah, is that weird that it's exactly on the hour? ...I guess not so weird, since 180 is divisible by 60.

Deleted Comment

codezero · 2 years ago
It’s funny how relevant this niche fact is for me. When I started my last job it was at 1.3 and I remember seeing it go through 1.4, 1.5 and 1.6 since I debugged a lot of data with timestamps. I remember commenting to my team about the 1.5 change and got some “so what” faces so I’m glad someone else looks at these changes as a sort of long term metronome like I did.
eliseetc · 2 years ago
Same here, I started to work at 1.4 and thought it'll never change.

Now I things it should be an occasion to open champagne with fellow developers, as it's rarer than new years!

James-Livesey · 2 years ago
Such an excellent coincidence that it happens to be on my birthday! In fact to celebrate, I did set up the only livestream in existence on YouTube (afaik) to capture this: https://www.youtube.com/live/DN1SZ6X7Vfo
franky47 · 2 years ago
Happy birthday! Here's a gift to help with numbers shifting place when updating:

    font-variant-numeric: tabular-nums;
https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...

mdaniel · 2 years ago
whew, seeing that makes me have bottomless sympathy for ladybird since I (quite literally) cannot imagine the amount of energy it would take to implement CSS in a modern browser

put another way: I'd get great thrills if any proposal to whatwg had to come bundled with the assembly(perl? bash? pick some language) implementation of any such proposal so the authors share the intellectual load of "but, wait, how would we _implement this_?!"

alexstore06 · 2 years ago
I can one-up you there - not only was it my birthday, it was my 17th as well :-)
koito17 · 2 years ago
Dang, I missed this by roughly an hour :(

I still remember when we were at 1.2 billion seconds. Time flies.

While we're still here: my favorite way to appreciate the scale of million and billion is with seconds: 1 million seconds is approximately 12 days, whereas as 1 billion seconds is approximately 31 years.

vecter · 2 years ago
Another fun one: pi * 1e7 seconds is approximately one year.
Someone · 2 years ago
Easier to remember: “pi seconds in a nanocentury”
x-complexity · 2 years ago
Lucky you: When I finally got onto HN, it's already been 2 hrs since then :(
benatkin · 2 years ago
I watched in `deno repl` neatly sandboxed :)

    new Date().valueOf() / 1000
I was counting down by thousands of seconds, rather than millions of milliseconds, which is why I divided instead of using the native js value.

Happy 1.7 gigaseconds!

jackconsidine · 2 years ago
Whoa didn't know about deno repl. This is awesome. Happy 1.7 gs!
benatkin · 2 years ago
Thanks! You can paste this into deno repl and watch the seconds count up :)

for (const [s, d] of (function*() { while (true) { const m=new Date().valueOf(), s=Math.ceil((m+10)/1000); yield [s, s*1000-m] } })()) { await new Promise(r => { setTimeout(()=>r(), d) }); console.log(s) }

rsynnott · 2 years ago
We draw close now to the (i32) end-times.
m463 · 2 years ago
I wonder about that. I expect the replacement system will allow timestamps after 2038, but will we also be able to timestamp files from pre-1970?
rsynnott · 2 years ago
The replacement system’s already here; modern OSes and software tend to use 64bit ints for timestamps.

The trouble is all the old embedded systems, and time_t->i32 casts which are currently fine, but lying in wait…

TheSoftwareGuy · 2 years ago
I think the easiest thing to do is to love to 64 but timestamps, not changing the epoch
JoshGlazebrook · 2 years ago
2038 is sure going to be an interesting year.
1970-01-01 · 2 years ago
It's our Mayan calendar moment :)
stabbles · 2 years ago
Relevant username
racl101 · 2 years ago
The Y2K moment for the new generation.
u801e · 2 years ago
At least on my system, it's not an issue:

    $ date --date="@2200000000"
    Sun Sep 18 07:06:40 PM EDT 2039

semanticc · 2 years ago
You are probably not running a 32-bit IoT device.
enva2712 · 2 years ago
It came fast, I’m barely done celebrating 1696969420
nurettin · 2 years ago
How do you celebrate that number?

Edit: nm, I don't want an answer.