
Unix Time 1500M – Friday July 14 02:40UTC - andreasklinger
https://www.epochconverter.com/countdown
======
schoen
I remember having a party for the billion seconds, which was on September 8,
2001 -- then overshadowed in my memory by the September 11 attack less than
three days later.

I also remember another party for Unix time 1234567890, back in 2009, which
got an impressive turnout.

[https://www.flickr.com/photos/estro/3304453623/in/photolist-...](https://www.flickr.com/photos/estro/3304453623/in/photolist-631bWk-635qTm)
[https://www.flickr.com/photos/briankusler/3278099542/in/phot...](https://www.flickr.com/photos/briankusler/3278099542/in/photolist-5ZF7MC)
[https://www.flickr.com/photos/estro/3305280994/in/photolist-...](https://www.flickr.com/photos/estro/3305280994/in/photolist-631bWk-635qTm)

At that party, I made some thyme tea, in honor of time_t. (Later on I learned
that thyme tea is actually a thing... I felt like I was just making it up!)

~~~
ianai
But seriously thyme tea sounds pretty awful.

~~~
andrei512
There are many kinds of thyme - one is good for tea (Thymus vulgaris) - but
they get confused a lot.

~~~
sdoering
Not only does it taste good (what might get debated) but it is said to help
against the common cold and stuff like that. Is being used for centuries now
as the "poor man's antibiotics".

------
tess0r
This remembers me of "primetime" a "clock" which draws a green bar every time
the timestamp is a prime.

[https://tessi.github.io/primetime](https://tessi.github.io/primetime)

Did it in my student years, looks awful today, but I was proud back then ;)

edit:

I just remembered that you can give it a timestamp to display (instead of just
displaying the current time). Unix Time 1,500M would be

[https://tessi.github.io/primetime/?t=1500000000](https://tessi.github.io/primetime/?t=1500000000)

and is (obviously) not a prime number.

~~~
plq
> looks awful today

I don't know what you don't like about it but I think not only that it looks
great, but also to me that's a design that's got character.

~~~
tess0r
* the green lines are somehow weirdly blurred (for god know what reason)

* it's hard to notice that the current timestamp is the most right (white or green) bar. Would be nice to have the current time in the center.

* It's hard to get the concept without explanation (at first glance people just see weird green bars moving).

But then, I never meant to make a perfectly polished clock. It's good for a
quick experiment.

------
squarefoot
Also, the PI date (3141592653) goes straight to Sunday July 21 2069; that's
exactly 100 years from the 1st human step on the moon.

~~~
jcahill84
That's super weird.

~~~
paradite
I think it is just one of the millions of possible coincidences. Yes, it's
fun, but nothing weird, because there are other millions of equally weird
coincidences that could happen.

------
simias
I don't get it, what's so special about 0x59682f00? 0x60000000, now that's a
nice round number. See you on January 14th 2021!

~~~
protomyth
Simias, we are surrounded by base 10 lovers in a binary world. These are the
same people who gave us terabyte hard drives with 1,000,000,000,000 bytes
which doesn't even make sense with sector sizes of 512 and 4096 bytes. I too
will celebrate the hex flip and not some shady base 10 shenanigans.

~~~
eridal
> Friday May 15 2015 02:09:25 GMT

That was 0x55555555 or b01010101010101010101010101010101

------
rdtsc
I am irrationally excited about this.

I suspect it's because now I'll be able to quickly glance at timestamps, say
in the logs or in data records, and estimate the time better without having to
use a script to translate it.

~~~
NickSharp
When I watch the constant progress of Unix time and milestones like this, I
really feel the passage of time in way I don't otherwise. Sometimes it freaks
me out.

~~~
rdtsc
Ah interesting. I agree. Wonder if it is because typical 12 or 24 hour clock
resets so we sort of get to "try again" during a new day. A continuously
increasing value that never resets just has a more ominous feel to it.

~~~
adrianN
It could be worse, it could be counting down.

~~~
TheSpiceIsLife
I thought of drawing a life-to-page calendar on my lounge room wall.

Decided against it as it would make it obvious how many days I've wasted and
how few I have left. Maybe that's all the more reason to do it.

~~~
adrianN
Try printing this [http://abstrusegoose.com/51](http://abstrusegoose.com/51)

------
JdeBP
Although the point where we reach 1.5 Ms since the Epoch actually occurs
slightly earlier at 2017-07-14 02:39:33 +0000 , as can be seen on a system
using Arthur David Olson's "right" timezones.

    
    
        jdebp % TZ=right/UTC date +"%s %F %T %z" -d "@1500000000"
        1500000000 2017-07-14 02:39:33 +0000
        jdebp %
    

* [https://unix.stackexchange.com/a/327403/5132](https://unix.stackexchange.com/a/327403/5132)

The timestamp in the headline is actually 1500000027 seconds since the Epoch.

~~~
d0mine
POSIX time doesn't count leap seconds (i.e., "seconds since the Epoch" are not
actually _elapsed_ seconds) and therefore POSIX time 1.5e6 is
2017-07-14T02:40:00 (UTC scale) _exactly_

right/UTC uses 1970-01-01 00:00:10 (TAI scale) epoch (it is slightly different
from 1970-01-01 00:00:00 (UTC scale) -- the Epoch)

2017-07-14 02:39:33 (UTC scale) is 2017-07-14T02:40:10 (TAI scale) i.e., it is
1.5e9 seconds since the epoch used for "right" timezones, not the Epoch.

~~~
JdeBP
No. Read the output of the date command and the aforementioned Stack Exchange
answer again. The Epoch was the same physical second in both the "right" and
the "posix" systems. It is 1.5 Gs (not Ms as I mistyped) since that second at
2017-07-14 02:39:33 +0000.

The fact that you've got a difference of 37 between your two values should be
a clue that you've got this wrong. The current difference between UTC and
TAI-10 is 27 seconds. Again, read the Stack Exchange answer for details.

And 1.5 Gs since the Epoch will be 2017-07-14 02:39:33 +0000 on _both_ "posix"
and "right" systems. A "right" wall clock _reads the same_ as a "posix" wall
clock, except at leap seconds of course. 2017-07-14 02:39:33 "posix" is the
same point in time as 2017-07-14 02:39:33 "right": 1.5 Gs since the Epoch. It
is _not_ the same point in time as 2017-07-14 02:40:10 "right"/"posix", which
is 1500000037 seconds since the Epoch.

    
    
        jdebp % TZ=right/UTC date +"%s %F %T %z" -d "@1500000037"
        1500000037 2017-07-14 02:40:10 +0000
        jdebp %
    

* [https://unix.stackexchange.com/a/294715/5132](https://unix.stackexchange.com/a/294715/5132)

~~~
d0mine
_wrong._ Don't confuse TAI and TAI-10. Don't confuse POSIX time [1] and
seconds since epoch (time() value) in "right" timezones.

On the "difference of 37": the current TAI-UTC == 37s [2] (10s from 1972 + 27
leap seconds).

On "the same physical second": look at the value of TAI-UTC in the period
before 1972 (if you plug the numbers then TAI-UTC is around 8 seconds at
1970-01-01 00:00:00 UTC, not 10s. The epochs are not the _same_. They are
"slightly different"). The _same_ physical second corresponds to 1972 (by
definition), not 1970:

    
    
      1972-01-01 00:00:00 (UTC scale) == 1972-01-01 00:00:10 (TAI scale) 
    

Note: :10, not :00, note: TAI, not TAI-10.

To reiterate:

POSIX time 1.5e9 corresponds to 2017-07-14T02:40:00 (UTC scale) _exactly_.

1.5e9 "seconds since epoch" (not the Epoch) for "right" timezones corresponds
to 2017-07-14T02:40:10 (TAI scale) == 2017-07-14 02:39:33 (UTC scale).

[1]
[http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16)

[2] [http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-
UTC_tab&la...](http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-
UTC_tab&lang=en)

( _the_ authoritative source on leap seconds. It publishes Bulletin C
ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE )

------
jonstokes
This page answers a question I was thinking about in the shower this morning:
what is the latest date (as a UNIX timestamp) you can store in a regular
postgres integer column, which has a max value of 2147483647 per the postgres
docs. It turns out that the answer is January 19 2038 03:14:07 GMT.

I'm working on a project that involves sync, and we're keeping track of action
numbers by incrementing the last action number, but for various reasons I was
thinking, "what if we replaced the action_number field with the corresponding
timestamp integer?"

Then I began to ponder which integer format to use -- if I could get a way
with just postgres integer, or if I needed to stop up to bigint. It turns out
I should probably step up to bigint if I do this :-)

Anyway, I could've just done this in ruby, but by the time I saw this I had
forgotten I was thinking about it, and this reminded me.

~~~
NoNotTheDuo
You've inadvertently discovered the "2038 Problem"[0]. This is the next
iteration of the Y2K bug.

[0]:
[https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

~~~
jonstokes
Well well... TIL

If I thought we'd all still be here in 2038 I'd have something new to worry
about :-/

------
dopeboy
For the bay area crowd - is there anything going on to celebrate?

------
rastapasta
2147483647 (2^31-1) is worth watching as well.

A second later the first bit of any timestamp still handled as signed int32
will flip and the ride into the past begins.

[https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

------
inertial
Marked my calendar for subsequent dates..

> date -ud @2000000000

Wed May 18 03:33:20 UTC 2033

------
Pete_D
A calendar of the upcoming 100M anniversaries:

    
    
        $ for x in {15..21}
        > do
        > printf '%2d %s\n' $x "$(
        >   env TZ=UTC date -d "@$(($x*100000000))"
        > )"; done
        15 Fri 14 Jul 02:40:00 UTC 2017
        16 Sun 13 Sep 12:26:40 UTC 2020
        17 Tue 14 Nov 22:13:20 UTC 2023
        18 Fri 15 Jan 08:00:00 UTC 2027
        19 Sun 17 Mar 17:46:40 UTC 2030
        20 Wed 18 May 03:33:20 UTC 2033
        21 Fri 18 Jul 13:20:00 UTC 2036
    

It's neat how they seem to roll around every pi years.

    
    
        >>> 1e8 / (3600 * 24 * 365.25)
        3.168808781402895
        >>> math.pi
        3.141592653589793

------
tbrock
Why is this milestone important?

~~~
flukus
Because many of us won't make it to 2 billion.

~~~
aaron695
15 years time?

~~~
gattilorenz
Surely you don't expect _everyone_ living now to be still alive in 15 years?
;)

But yeah, it might just indicate that parent got the ballpark estimate
wrong... Unix time is not the most human-friendly format.

~~~
adrianN
A simple mnemonic is that pi * 10 ^ 7 seconds is a year (~0.5% error) and e *
10 ^ 6 seconds is a month.

~~~
scottmf
Simple indeed.

------
Sir_Substance
I get that little popup on this website saying "you agree to our use of
cookies to give you the best possible experience".

Why do I need cookies to maximize my unix time experience, exactly?

------
nitramm
If you want to avoid converting seconds into something more human readable,
you can use
[http://timestamp.online/countdown/1500000000](http://timestamp.online/countdown/1500000000)

What is the next timestamp you are looking for?
[http://timestamp.online/countdown/1515151515](http://timestamp.online/countdown/1515151515)
or is there something better sooner?

~~~
JdeBP
This one is sooner.

    
    
        jdebp % echo @400000005a00000000000000|TZ=UTC tai64nlocal
        2017-11-06 06:23:23.000000000
        jdebp %
    

This one is slightly later.

    
    
        jdebp % echo @400000005a5a5a5a005a5a5a|TZ=UTC tai64nlocal
        2018-01-13 19:12:53.005921370
        jdebp %

------
tbking
I've seen the Unix timestamp as One Four something since I started active
coding since 2015. So I'm excited about this.

~~~
lucb1e
Twelve-billioner here (or was it 11-bil? hmm). Sounds like we're onto a new
measure of work experience!

~~~
majewsky
Actually, you would be either a 1.2 or 1.1-billioner. It's an order of
magnitude less.

~~~
lucb1e
Oops, you're right.

------
wincent
Obligatory link to macOS "epoch flip clock" screensaver:
[https://github.com/chrstphrknwtn/epoch-flip-
clock](https://github.com/chrstphrknwtn/epoch-flip-clock)

------
peter_retief
My cars odometer is at 99910km's so by tomorrow I should be at 100000km's, not
quite date -d @1500000000

------
amelius
For anyone wondering, an increment like this happens about every three years.

------
ben174
date +%s

To see current time

~~~
smnscu
I used to find this syntax opaque/unfriendly until I simply looked into it.
Here's a helpful cheat sheet for what follows the "+":

[https://gist.github.com/nikreiman/1408399](https://gist.github.com/nikreiman/1408399)

~~~
lucb1e
Or just use man date

------
dmihal
What's everybody doing to celebrate?

~~~
CodeWriter23
Honestly, I'm going to shrug my shoulders. Not to dampen anyone else's
celebrations and enthusiasm. That's just how I am about these kind of things.
Like on most Birthdays, the orbital relationship of Earth to Sun isn't even
within millions of miles of when I was born, so I'm like "meh". Except for my
DD's birthday, but that's because it's special to her.

~~~
smnscu
Thanks for eloquently putting in words how I feel about this. I yearn for a
life so uneventful and devoid of stress that I could give two shits about such
things.

~~~
vacri
And yet it piqued your curiosity enough to read comments on the issue.

------
vectorEQ
5.0E+96 count down to that lol... funny site tho :D for some reason i approve
of this.

------
vacri
I'm going to be 1.5B seconds old! I mean, whenever $random_website demands my
birthday, they get Start of Epoch. Easy fake birthday to remember :)

------
gridscomputing
yawn. is this the HN equivalent of a 4chan "GET"?

~~~
quickthrower
What's a 4chan GET?

~~~
poooogles
All posts incrementally increase as posts accumulate on a board. Gets are
normally reserved for when you approach a milestone. Example here
[http://new3.fjcdn.com/pictures/Fj+gets+banned+from+4chan_660...](http://new3.fjcdn.com/pictures/Fj+gets+banned+from+4chan_660e83_5439181.png).

Classically you'd say something is true if you get dubs (the post id ends in
doubles)

~~~
Kiro
Why is it called GET?

~~~
lmm
Common English loanword in Japanese, or at least in anime - characters will
excitedly say something like "prize GET" (with the "get" in English and
shouted, the "prize" in Japanese, but rendered that way by fan translations).

