11 ms·
Unix Time reaches 1.7 billion
- rsynnott 3y agoWe draw close now to the (i32) end-times.
- m463 3y agoI 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?
- TheSoftwareGuy 3y agoI think the easiest thing to do is to love to 64 but timestamps, not changing the epoch
- rsynnott 3y agoThe 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…
- stabbles 3y agoThe replacement is not without issues: each package can pick an ABI, nothing is enforced. A define in C toggles time_t between 32 and 64 bits, so if that struct is exposed in a library, dependents have to deal with it. Similar of course to 32 vs 64 bit file offsets.
- deleted 3y ago[deleted]
- dylan604 3y ago>but lying in wait… This brings back memories of all of the Y2K doomsayers about airplanes falling out of the sky, gas pumps not working, and all of the other just wildly bonkers theories people came up with. Even without the help of social media, these notions spread like wildfire.
- wizzwizz4 3y agoPlanes will be fine; but many of those things actually will happen as a result of Y2038. Embedded systems with ancient versions of Linux will stop being able to verify certificates, and I bet there are some digitised pumps that rely on that.
- doublepg23 3y agoA lot of stuff would have broken during y2k if a lot of engineers hadn't put in a massive effort. We know this because we just changed the clocks to 2000 and things broke...badly.
- dylan604 3y agoI wasn't suggesting it wasn't a real issue that needed solving. Just that the end of days scenarios were blown well out of proportion. The preppers community really came into their own and out of the shadows. Even my ex-in-laws were buying drums full of flour and what not storing them in their suburban backyard.
- conradludgate 3y agoIf they weren't blown out of proportion, they might not have been fixed and the bad situations might have happened. Sometimes you need to spread fear to get stuff fixed. But then people think "oh it wasn't that bad, those engineers are just the boy who cried wolf" and then next time they won't take us seriously
- hoseja 3y agoFlour? That sounds unoptimal. Probably rice would be better?
- dylan604 3y agoAnd what not. You missed that bit trying to be smart. Their whole 8’ wooden privacy fence was lined with weatherproof blue drums full of various foodstuff. Yes, they had rice, beans, various grains. I’m not a damn prepped, so I just rolled my eyes at the whole thing. I always assumed the weatherproof wasn’t really and it would all be ruined after the first rain. But yes smarty pants, they had all of that stuff. Don’t you feel good about yourself now?
- fabianhjr 3y agoWish you all good health and fortune until 2.0 short billion > Wednesday May 18 2033 03:33:20 GMT
- throwitaway222 3y agoThe REAL big non-event that no one cares about is this one: https://www.epochconverter.com/countdown?q=2000000000 https://www.epochconverter.com/countdown?q=2000000000
- AlwaysNewb23 3y agoI'll remember to post that in 2033.
- jayknight 3y ago>In human years, the UNIX timestamp is about 80. It's 53, right? Since 1 Jan 1970?
- qup 3y agoit aged quickly during the stressful period of Y2K
- DamonHD 3y ago1699996851
- vasdae 3y ago[dead]
- m0d0nne11 3y agowhile date '+%s'; do sleep 1; done
- moneal 3y ago$ date -r 1700000000 Tue Nov 14 14:13:20 PST 2023
- sigmonsays 3y agosee you in 4 years... $ date -d @1800000000 Fri 15 Jan 2027 12:00:00 AM PST
- llamaInSouth 3y agois that really 4 years
- 1970-01-01 3y agoNeat!
- simonblack 3y agoAnd .... ?? Not only that, it's almost 9AM. Sorry, but I can't see what the big deal is supposed to be. Maybe I'm missing something.
- deleted 3y ago[deleted]
- paulddraper 3y agoLots of zeroes my guy
- dumpHero2 3y agoThis guy must be fun at new year parties.
- UUID_KING 3y agohttps://www.youtube.com/watch?v=Szdziw4tI9o https://www.youtube.com/watch?v=Szdziw4tI9o Theme music. :)
- antiquark 3y agoFew seconds left.... https://www.epochconverter.com/ https://www.epochconverter.com/
- borbtactics 3y agoWe get to celebrate every three years? Nice
- SPHINXc-- 3y agoActually a cool date pivot point. Did not realize it was coming up (and has now passed). Thanks.
- ChrisArchitect 3y agoThe heads up last week: https://news.ycombinator.com/item?id=38222909 https://news.ycombinator.com/item?id=38222909
- dang 3y agoThanks! Macroexpanded: The Unix timestamp will begin with 17 this Tuesday - https://news.ycombinator.com/item?id=38222909 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 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 https://news.ycombinator.com/item?id=33316429 - Oct 2022 (116 comments) Happy 1600M epoch second - https://news.ycombinator.com/item?id=24460382 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 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 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 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 https://news.ycombinator.com/item?id=475437 - Feb 2009 (3 comments)
- raverbashing 3y ago> Feb 2009 (3 comments) Interesting. And one of those comments was mentioning an EEEpc. Simpler times indeed. Seems like HN grew the most between then and 2014, continuing up to 2020
- 3y ago
- xeckr 3y agoI opened Node.js and did setInterval(() => console.log(Date.now()), 1); to watch the transition. Happy 1.7B seconds since Jan 1 1970!
- jackconsidine 3y agoWe had our game of code-names self destruct at the exact moment using very similar code. Good times
- benatkin 3y agohmm, it didn't occur to me to use a timer rather than hit the up arrow and enter. Now I have this to watch the time count up :) async function* seconds() { while (true) { const millis = new Date().valueOf() const seconds = Math.ceil((millis + 10) / 1000) const delay = (seconds * 1000) - millis await new Promise(r => { setTimeout(() => r(), delay) }) yield seconds } } for await (const s of seconds()) { console.log(s) }
- xeckr 3y ago>async generator >for await (const s of seconds()) I'd hate to be your code reviewer!
- ftmch 3y agoFun fact: setInterval() might not be the most accurate timer, as it might drift after a while.
- lagrange77 3y agoAre we supposed to clink our calculators now?
- grahamm 3y agoI filmed it on my phone so I can watch it roll over later...
- benatkin 3y agoI 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 3y agoWhoa didn't know about deno repl. This is awesome. Happy 1.7 gs!
- benatkin 3y agoThanks! 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) }
- deleted 3y ago[deleted]
- lakpan 3y agoIs that like a reverse codegolf? setInterval(() => console.log(Math.ceil(Date.now()/1000)), 1000);0 This could be 0.999s late, but seems good enough for REPL usage
- benatkin 3y agoIt doesn't just handle the gap but when the first one sends. Suit yourself, though.
- chrismorgan 3y agoThat seems rather convoluted. The generator function is gratuitous, and the promise stuff is unfortunately verbose (pity there’s no async version of setTimeout built in). I’d write it with a recursive function, this way: function t(){let m=Date.now(),s=Math.ceil((m+10)/1000);setTimeout(()=>{console.log(s);t()},s*1000-m)}t() That maintains the accuracy, but frankly just a 1000ms interval will probably be good enough in most cases, though it’ll drift all over the second (e.g. it loses about a millisecond each tick on my machine under Node), and it’s certainly much simpler to reason about.
- JoshGlazebrook 3y ago2038 is sure going to be an interesting year.
- 1970-01-01 3y agoIt's our Mayan calendar moment :)
- u801e 3y agoAt least on my system, it's not an issue: $ date --date="@2200000000" Sun Sep 18 07:06:40 PM EDT 2039
- semanticc 3y agoYou are probably not running a 32-bit IoT device.
- XorNot 3y agoFeels weird to be almost 1900 seconds in this bold new number right now!
- James-Livesey 3y agoSuch 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 https://www.youtube.com/live/DN1SZ6X7Vfo
- franky47 3y agoHappy 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-variant-numeric https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...
- mdaniel 3y agowhew, 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_?!"
- pikelet 3y agoThese are important typographical features and I'm fairly sure this is handled by font rendering libraries, not the browser (other than handling the CSS rules), so I can't imagine it's that difficult to implement? Correct me if I'm wrong!
- johncolanduoni 3y agoIt’s handled by text shaping libraries (e.g. Harfbuzz in Chrome and Firefox), not font rendering APIs (usually provided by the OS), but you have the right idea.
- alexstore06 3y agoI can one-up you there - not only was it my birthday, it was my 17th as well :-)
- JCharante 3y agoOh wow. Is it strange that I remember the 1600M epoch second?
- bertil 3y agoIt was only 100M seconds ago…
- tempestn 3y ago100,000,000 / 60 / 60 / 24 / 365 = 3.17 years
- philsnow 3y agonot at all, I remember 1234567890
- philihp 3y agoI remember you remembering that when we celebrated 1500000000!
- JCharante 3y agoStrangely enough, I once read a comment about a kid saying to himself that he will remember a specific but insignificant moment, and ever since then (maybe 8 years) I can recall saying to myself "I will remeber this".
- joncp 3y agoI remember where I was when we hit 1,000,000,000. My coworkers thought I was strange for thinking it was significant. ... two days later all hell broke loose.
- tambourine_man 3y agoI thought it was sept 11 and went on to check. Indeed it was.
- mulmen 3y agoTo all of you that wrote adhoc scripts to “see” this happen, what are you doing to preserve them so they work for 1.8 gigaseconds on January 15, 2027? I lost my 1.6 gigasecond script because it was on a work laptop at a previous role.
- dylan604 3y agoI'll just utilize my skills as a programmer to rewrite the script. I never reuse code written for a different employer. That's unethical. If you're the type to use other peoples code, I'm sure you could just npm install your way through it though (or whatever package manager du jour will be)
- Someone 3y agoI think the best solution to that is to create an appointment in you calendar or a reminder in your todo-app with that ad hoc script in a comment.
- koito17 3y agoDang, 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 3y agoAnother fun one: pi * 1e7 seconds is approximately one year.
- Someone 3y agoEasier to remember: “pi seconds in a nanocentury”
- x-complexity 3y agoLucky you: When I finally got onto HN, it's already been 2 hrs since then :(
- codezero 3y agoIt’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 3y agoSame 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!
- JohnMakin 3y agohah! noticed this because I was testing some logic and a timestamp popped up at exactly 1.7 billion and some decimal.
- droptablemain 3y agoCountdown to 2147483647 https://www.epochconverter.com/countdown?q=2147483647 https://www.epochconverter.com/countdown?q=2147483647
- shric 3y agoSurely you mean https://www.epochconverter.com/countdown?q=2147483648 https://www.epochconverter.com/countdown?q=2147483648
- foxylad 3y agoHad a weird timestamp bug yesterday, and I did (stupidly) consider if it was an artifact of hitting 1.7 billion seconds.
- shpx 3y agoIt should be 63835596800 (63.8 billion) because it was kind of self-centred to start counting from 1970 instead of year 1. It doesn't make sense to make memorizing a 4 digit number a prerequisite to becoming a programmer.
- BillinghamJ 3y agoThe year 1 is also completely arbitrary though? Humans existed long before then too. It doesn't really matter when the epoch is, as long as everyone uses the same one, and negative values are supported as appropriate
- shpx 3y ago> as long as everyone uses the same one Exactly my point. The rest of humanity uses year 1 as the epoch.
- imrehg 3y agoCalling in from year 112 in Taiwan currently, hello, hello.
- deleted 3y ago[deleted]
- shpx 3y agoThe internet is telling me that Taiwan uses both calendars. Is that not true? Surely even your grandparents know that it's 2023 in the rest of the world. It's irrelevant to my point though. Just because the standard is used by 99% of people instead of 100% doesn't mean programmers should invent a new one, for the same reason they chose January 1st 1970 and not November 15th 1970 or any other day of the year. There's only one obvious choice.
- someone7x 3y ago> Exactly my point. The rest of humanity uses year 1 as the epoch. The rest of humanity uses a variety of reckoning systems: https://en.m.wikipedia.org/wiki/Calendar_era https://en.m.wikipedia.org/wiki/Calendar_era
- aidenn0 3y agoI was in college when it hit 1 billion. I feel old now.
- jeffbee 3y agoI want to use this opportunity to flog one of my favorite topics: whether or not to store epoch time using variable-length numbers in protobuf. TL;DR: never do this If you are storing the epoch offset in seconds, you could store it as int32 or fixed32 (assuming the range is adequate for your application). But int32 will need 5 bytes, while the fixed32 field would only use 4. So you never save space and always spend time using int32. Similarly, if you are storing the offset as nanoseconds, never use int64. Except for a few years on either side of the epoch, the offset is always optimal in a fixed64. int64 will tend to be 9 bytes. Fixed64 nanoseconds has adequate range for most applications. You'll note that the "well-known" google.protobuf.Timestamp message commits both of these errors. It stores the seconds part as a varint, which will usually be at least 5 bytes when it could have been 4, and it stores the nanoseconds separately in an int32, even though this is more or less an RNG and is virtually guaranteed to need 5 bytes, if present. So nobody should use that protobuf. Thus ends this episode of my irregular advice on how to represent the time.
- willsoon 3y agoHappy 1.7 and prosper next!
- johnea 3y agoTue 14 Nov 2023 02:13:17 PM PST = 1699999997 Tue 14 Nov 2023 02:13:18 PM PST = 1699999998 Tue 14 Nov 2023 02:13:19 PM PST = 1699999999 Tue 14 Nov 2023 02:13:20 PM PST = 1700000000 Tue 14 Nov 2023 02:13:21 PM PST = 1700000001 Tue 14 Nov 2023 02:13:22 PM PST = 1700000002 Tue 14 Nov 2023 02:13:23 PM PST = 1700000003
- zzzcsgo 3y agoNot sure why this is significant
- matheusmoreira 3y agoHumans love repeating digits.
- xyst 3y agoIn 5180 days, unix time will overflow.
- mlhpdx 3y agoOkay, so at what value will the Unix timestamp equal the human population? I should start a pool…
- enva2712 3y agoIt came fast, I’m barely done celebrating 1696969420
- nurettin 3y agoHow do you celebrate that number? Edit: nm, I don't want an answer.
- u801e 3y agoAs for what the future holds: $ date --date="@1800000000" Fri Jan 15 03:00:00 AM EST 2027 $ date --date="@1900000000" Sun Mar 17 01:46:40 PM EDT 2030 $ date --date="@2000000000" Tue May 17 11:33:20 PM EDT 2033
- gumby 3y agoWhat's with the fetish for round numbers in, of all things, base 10?
- StevePerkins 3y agoNot to be a wet blanket, but I'm really surprised to see posts about this all over social media today. This isn't even a nice round number, and we hit a new decimal value every 5 years or so.
- snthpy 3y agoOT but may be of interested to folks that find this kind of numerology fun. Your 10_000 th day passes when you're 27.x years old (IIRC). I had a celebration with friends as it seemed more significant than any of the other milestones that are usually celebrated because you won't reach 100_000 and don't remember 1_000. Can recommend!
- KwanEsq 3y agoInteresting if morbid bit of serendipity that that should occur during the age of 27 when the 27 club also exists.
- seydor 3y agoi have a countdown on my phone that counts the days left until i am 80, when i expect to die. Makes life more interesting
- vincent-manis 3y agoBut what if your phone goes first?
- seydor 3y agogonna live forever
- seydor 3y agoin decimal
- cplli 3y agoDon’t forget to update your regex appropriately (/s hopefully)
- msravi 3y agoDoesn't the 100M mark rollover every 3 yrs and change? What's the big significance of the 1.7B mark?
- opan 3y agoIf it only comes once every 3 years, it's at least as notable as a new software release, which is something that often gets posted here.
- tw1984 3y agoI don't use Unix time. If someone gives you a Unix time timestamp x, it doesn't mean much unless you check it against a list of leap seconds. By default, your fancy unix time timestamp X doesn't point to a unique second in history, for dozens of times, it pointed to some pretty random 2 seconds intervals. TAI is the only sane choice if you do understand what you are doing. Btw, if you already know that leap second is dead and wondering what happens next, well, they are going to implement leap minute, the good news is you are unlikely to see one in your life time. They are meeting next week to decide on this leap minute proposal. https://www.nytimes.com/2023/11/03/science/time-leap-second.html https://www.nytimes.com/2023/11/03/science/time-leap-second....
- ezekiel68 3y agoAnd yet... the Sun stubbornly insists on coming up each morning. Therefore, TAI cannot be "the only sane choice" or else the conversion would have happened by now. Either off-by-n leap seconds don't matter enough, or periodically sync'ing with good NTP authorities mitigate it without undue harm. Or ?
- SAI_Peregrinus 3y agoUse the time standard that's best suited to your use case. Of course that requires understanding time standards at least a bit. Usually the differences will be minor, but they can matter for things like navigation. Use TAI if you want a monotonic time. UNIX time and GPS time work too, they're fixed offsets from TAI. Use UTC if you want a calendar date/time. Most human interactions are with time zones relative to UTC. Those two cover almost all the cases you'll need. Use UT1 if you want time that roughly tracks the solar time, averaging out the differences in day length due to earth's tilt & elliptical orbit. Use apparent solar time if you really care about calculating where the sun is or will be for some reason and can't just point your solar telescope at it. Use sidereal time if you're trying to calculate where extrasolar objects will be. Use barycentric coordinate time (TCB) if you're plotting the trajectories of interplanetary spacecraft missions or the ephemerides of planets. Various religions have their own time standards used to calculate when holidays occur. There are a few others still usable, even more niche than the above. Use one of the first two and you'll probably be fine.
- giovannibonetti 3y agoSince we're less than a decade away from the doomsday point, I wonder if it would be easier to transition from signed to unsigned 32 bits, as it would buy everyone multiple decades to transition to something else. Also, this first transition should be less disruptive than any other one, since the unsigned format is backwards compatible with the current signed one in its current usage (positive numbers).
- 6031769 3y agoThe epochalypse is well over a decade away.
- Someone 3y ago> since the unsigned format is backwards compatible with the current signed one in its current usage (positive numbers). For existing binaries (many of them burned in ROM) it is that much compatible that it will also break at the same time as the current system. So, you need new binaries. If you do, why limit yourself to 32 bits? Also, I’m not sure all current usage is for positive numbers, only. Using time stamps for datetimes isn’t what you should do, but chances are older software does it, anyways, because memory was expensive up to the 1980s, and those dates may have been before 1970.
- classified 3y ago1.7e9 is a rather crooked time stamp. 1.8e9 is much neater.
- Heliodex 3y agoI told myself I wouldn't miss it this time D: Welp, time to wait another 3 years. No way I'm missing the Epochalypse.
- grey_earthling 3y agoDividing the Unix time by 100,000 produces a (currently) 5-digit number that increments every ~28 hours, and behaves pleasingly like a stardate. (It doesn't align with any of the various stardate systems actually used in the different Star Trek series and films, but aesthetically it's similar enough to be fun.)
- spike_protein 3y agoI'm looking forward to "The 2038 Problem"
- simne 3y agoRespectable reason to drink :)))