
Happy 1600M epoch second - bajsejohannes
https://www.epochconverter.com/
======
bloopernova
Dagnabbit I overslept!

I use BitBar on my macbook to display the epoch second on my menu bar in a
format like this: { 1,600,003,345 }

The script to do that is:

    
    
        EPOCH=$(/bin/date +%s | /usr/local/bin/sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')
    
        echo "{" "${EPOCH}" "}"
    

Separating the epoch into thousands was done with the help of this
Stackoverflow question: [https://unix.stackexchange.com/questions/113795/add-
thousand...](https://unix.stackexchange.com/questions/113795/add-thousands-
separator-in-a-number)

EDIT: This is a much simpler way of writing it, thanks to GNU Coreutils'
"numfmt"

    
    
        EPOCH=$(/bin/date +%s | /usr/bin/numfmt --grouping)

~~~
pwg
GNU coreutils printf also supports insertion of thousands separators with the
' format flag, which gives another way to add them to numbers:

EPOCH=$(printf "%'d" $(date +%s))

~~~
bloopernova
Very cool, thank you for sharing :)

------
susam
Here is a screenshot I took at Unix timestamp 1600000000:
[https://twitter.com/susam/status/1305120936098627589](https://twitter.com/susam/status/1305120936098627589)

Reproduced as text below:

    
    
      $ date -u; date; date +%s
      Sun Sep 13 12:26:39 UTC 2020
      Sun Sep 13 17:56:39 IST 2020
      1599999999
      $ date -u; date; date +%s
      Sun Sep 13 12:26:40 UTC 2020
      Sun Sep 13 17:56:40 IST 2020
      1600000000
    

An important point worth noting from the POSIX.1-2008 specification:

"Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX
time (seconds since the Epoch), leap seconds are ignored (not applied) to
provide an easy and compatible method of computing time differences. Broken-
down POSIX time is therefore not necessarily UTC, despite its appearance."

See
[https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd...](https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16)
for more details on the above point.

By the way, in case you got curious like me to find out if this Hacker News
story (the original post) was posted exactly at this time, the answer is, it
was posted at Unix timestamp 1599999975. See [https://hacker-
news.firebaseio.com/v0/item/24460382.json](https://hacker-
news.firebaseio.com/v0/item/24460382.json) for the details.

~~~
bjo590
> leap seconds

Over long periods of time the approximation that a day takes 86400 SI seconds
will become less and less accurate as the rotational period of the Earth
changes. I wish calendars would be either purely astronomical in nature or
purely SI in nature. Hybrid systems like UTC become more and more messy over
time as the amount of adjustment needed increases. We've had ~25 leap seconds
in UTC already, and it's a relatively young calendar system.

EDIT: I also wish we would change the name of the SI measurement "second". An
SI second and an astronomical second are two different things, and deserve two
different names.

------
trollied
Example of an associated bug:
[https://community.splunk.com/t5/Archive/Splunk-Y2K-type-
bug-...](https://community.splunk.com/t5/Archive/Splunk-Y2K-type-bug-arriving-
on-September-13-2020/m-p/480856/highlight/true#M90101)

~~~
scrollaway
How the hell do regexes like these find their way into production …

~~~
mannykannot
There's an example of the sort of chronic (pun intended) patch-driven-
development, YAGNI(Y) thinking that leads to this sort of thing, in the last
paragraph:

"For instances that can't/won't get updated in time, this Splunk app can be
deployed as a workaround. The app executes bash/Powershell at Splunk startup
to check for the above regex _and add a '6' if needed._ It may not be the best
fix, but it does kick-the-can on the problem for another 3 years, at least
until epoch time reaches 1.7e10."

Someone, somewhere is saying "but it passed all the unit tests..."

~~~
a1369209993
> at least until epoch time reaches 1.7e10.

And to add insult to injury: that should actually be 1.7e9; 1.7e10 would be
17000M epoch seconds, not 1700M.

------
secabeen
I celebrated the Billenium with my brother (two days before 9/11, actually).
He's dead now, and we didn't have a lot of shared interests, so it'll always
be a nice memory for me.

~~~
anon9001
I remember being in #billenium on openprojects (before it was called freenode)
at the time. Really neat shared community experience.

------
parenthesis
Less than eighteen years until 19th January 2038!

------
jasoneckert
Sweet 16 seems fitting here, considering that Unix/Linux systems have gained
so much momentum over the past decade (even Lenovo started shipping Fedora on
laptops this month).

------
input_sh
I've recorded a video if someone wants to relive it for whatever reason:
[https://twitter.com/input_sh/status/1305122125250990080](https://twitter.com/input_sh/status/1305122125250990080)

------
foxcpp
There we go, humanity survived for another _insert description of time
interval_

------
aljgz
in Gif:
[https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif](https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif)

------
dmitshur
Woohoo!

Next one (1700M) will be on 2023-11-14 22:13:20 +0000 UTC.

~~~
trebligdivad
Which makes me why this got so much traction; meh it's only every 3 yearsish.

~~~
Retr0spectrum
That means it's 3x more significant than New Year's Eve!

------
jwalton
"There were programs here that had been written five thousand years ago,
before Humankind ever left Earth. The wonder of it—the horror of it, Sura
said—was that unlike the useless wrecks of Canberra’s past, these programs
still worked! And via a million million circuitous threads of inheritance,
many of the oldest programs still ran in the bowels of the Qeng Ho system.
Take the Traders’ method of timekeeping. The frame corrections were incredibly
complex—and down at the very bottom of it was a little program that ran a
counter. Second by second, the Qeng Ho counted from the instant that a human
had first set foot on Old Earth’s moon. But if you looked at it still more
closely…the starting instant was actually about fifteen million seconds later,
the 0-second of one of Humankind’s first computer operating systems."

\- A Deepness in the Sky, Vernor Vinge

~~~
JdeBP
Look at it yet more closely even than that, however, and you'll find that it
isn't the year that that operating system was invented, nor the year of its
1st Edition, nor even the way that it counted time before 1974. It was simply
a year that, in the words of one of its creators, "seemed to be as good as
any" (dmr, _Wired_ , 2001).

------
xwdv
The end of an era, I’ll be glad to see 1600M timestamps with a lot more zeroes
in them now. Feels like the future.

------
hamaki
This is gonna be weird seeing timestamps starting with 16- from now on

~~~
karmakaze
Sort of like I remember the rollover from 9.. to 1000000000 in 2001 like it
wasn't all that long ago as I was well into my career. It must have been a
notable moment as I remember that I was doing some consulting work hooking up
remote datasources for some telecom apps.

~~~
jlgaddis
Our local Linux User Group (now defunct) had a "special event" to celebrate
the occasion (although I didn't realize ~19 years have since past!).

Unfortunately, the bakery we got the cake from was unable to satisfy our
request for 1000000000 candles on the cake.

~~~
karmakaze
Yeah the seconds since must me shorter. You could've gone for 31.7 candles but
it doesn't have the same splash.

------
joshxyz
Life is fleeting.

~~~
disown
Time flies.

~~~
Ancapistani
Time flies like an arrow. Fruit flies like bananas.

------
calvinmorrison
Did anyone get alerts so far on a Sunday morning? Suddenly one of my replicas
is reporting suspiciously behind but not actually

~~~
AbacusAvenger
My apartment building had a very brief (less than a few seconds) power outage
at the time 1600M seconds rolled over. Weird.

------
Commodore_64
Happy 1600

------
agustif
[https://www.unixtimestamp.com/](https://www.unixtimestamp.com/) The Current
Unix Timestamp 1600001210 seconds since Jan 01 1970. (UTC)

