Hacker News new | ask | show | jobs
by SPHINXc-- 951 days ago
Actually a cool date pivot point. Did not realize it was coming up (and has now passed). Thanks.
2 comments

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)

> 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

next one is in 3 years
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.

Does that mean unix date calculations do not take into account the leap second?

https://en.m.wikipedia.org/wiki/Leap_second

That's a long page, but basically the answer is no. We don't randomly have a 61 second minute in "clock" units; instead we have a day that takes 86401 _real_ seconds but only the standard 86400 clock seconds.

By way of analogy, imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29.

> imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29

Thanks I will imagine this! Too bad we can’t slow the real Earth time down and have a bizarrely slow and long day every 4 years.

Leap hours would be neat!
And it's intentional, so each day has exactly 86400 seconds, even though it doesn't correspond to UTC.

In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time.

> In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time.

This. If anyone is interested in a source:

https://www.scientificamerican.com/article/the-leap-seconds-...

Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC.

When you run "date", it asks the system for this number of seconds, then uses a database to look up what that number corresponds to in the local timezone, accounting for leap years and seconds, and spits out that value. So when (some of us) recently "fell behind", the Unix time incremented by 1 second, but that database told us that the time had decreased by an hour.

Not exactly sure how Windows does it, but I recently set up monitoring of a job that Task Scheduler runs, starting at midnight and running for 1 day, every 5 minutes. I got paged at 11:30 because the scheduler decided "1 day" is "24 hours", and it stopped running it at 11pm because of the time change, but didn't start the one for the next day.

I know cron can be confusing, but I'll take it any day over this.

> Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC.

Wrong. UNIX time is number of days since epoch × 86400 + seconds since beginning of day.

In real world some days have been actually 86401 seconds long, which means that UNIX timestamp is (currently) 37 less than number of seconds since epoch.

Go ahead and correct it on Wikipedia, I double-checked my understanding against the entry there before posting my message, and re-reading it I think my description matched Wikipedia.

You'll also need to correct it in the time(2) man page, which says:

"number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)." (ubuntu 22.04)

https://en.wikipedia.org/wiki/Unix_time

Then parent was correct but `s/UTC/TAI/g`; no counting of days nor multiplication required.
They do not, no.

You can do things like find midnight GMT by checking (t % 86400 == 0) for example.