[HN Gopher] Happy 1700M Epoch Second
       ___________________________________________________________________
        
       Happy 1700M Epoch Second
        
       Author : jackconsidine
       Score  : 131 points
       Date   : 2023-11-14 22:14 UTC (45 minutes ago)
        
 (HTM) web link (www.epochconverter.com)
 (TXT) w3m dump (www.epochconverter.com)
        
       | SPHINXc-- wrote:
       | Actually a cool date pivot point. Did not realize it was coming
       | up (and has now passed). Thanks.
        
         | hmaxwell wrote:
         | next one is in 3 years
        
           | SamBam wrote:
           | 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.
        
             | radarsat1 wrote:
             | Does that mean unix date calculations do not take into
             | account the leap second?
             | 
             | https://en.m.wikipedia.org/wiki/Leap_second
        
               | jolmg wrote:
               | https://unix.stackexchange.com/questions/758932/unix-
               | time-le...
        
         | ChrisArchitect wrote:
         | The heads up last week:
         | https://news.ycombinator.com/item?id=38222909
        
       | xeckr wrote:
       | I opened Node.js and did                 setInterval(() =>
       | console.log(Date.now()), 1);
       | 
       | to watch the transition. Happy 1.7B seconds since Jan 1 1970!
        
         | jackconsidine wrote:
         | We had our game of code-names self destruct at the exact moment
         | using very similar code. Good times
        
         | benatkin wrote:
         | hmm, 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)         }
        
       | lagrange77 wrote:
       | Are we supposed to clink our calculators now?
        
       | benatkin wrote:
       | 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 wrote:
         | Whoa didn't know about deno repl. This is awesome. Happy 1.7
         | gs!
        
       | rsynnott wrote:
       | We draw close now to the (i32) end-times.
        
         | m463 wrote:
         | 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?
        
           | TheSoftwareGuy wrote:
           | I think the easiest thing to do is to love to 64 but
           | timestamps, not changing the epoch
        
           | rsynnott wrote:
           | 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...
        
       | JoshGlazebrook wrote:
       | 2038 is sure going to be an interesting year.
        
       | XorNot wrote:
       | Feels weird to be almost 1900 seconds in this bold new number
       | right now!
        
       ___________________________________________________________________
       (page generated 2023-11-14 23:00 UTC)