Client: "Do you think we could finish specs in week 33, see a demo in week 35, and aim for the product to be finished in week 39?"

I jump on the conference room table, rip the shirt off my sweaty chest, and yell:

"WEEKS OF WHAT? 31 WEEKS SINCE YOU BECAME A CLIENT, 35 WEEKS FROM NOW, 39 WEEKS INTO THE PREGNANCY? BLOODY FUCKING HELL MAN, DO YOU HAVE TO TALK LIKE A RETARD?"

Client, unfazed: "Weeks since the start of the year, sir"

Me, swinging my pants above my head like a lasso:

"WHAT THE FUCK KIND OF SNOWFLAKE ARE YOU, YOU REALLY EXPECT ME TO COUNT THE WEEKS SINCE THE START OF THE YEAR? WHAT ABOUT JUST USING DAY OF THE MONTH YOU OBNOXIOUS DIMWIT?"

Client: "We always use weeks at our company to plan things"

Me, winding the legs of my pants around the neck of the client:

"I HATE IT WHEN PEOPLE USE WEEKNUMBERS, JAKE. I. FUCKING. HATE. IT."

Client, still pretending everything is fine: "If you want I could send you a screenshot of my outlook calendar?"

Me, sitting in underpants on the client's back, sweaty legs wrapped around his waist, trying to pull out his gel-infested manager-hair while strangling him with my pants:

"TIME OF DEATH, UNIX TIMESTAMP 1595240810, ISO 8601 DATE 2020-07-20T10:26:50+00:00. ANOTHER PROJECT SUCCESSFULLY WRAPPED UP"

(parts of this story may have been dramatized to reflect my underlying emotions)

Let's just appreciate the fact the Unix timestamp will reach 1500000000 on july 14th :)

Happy Epoch + 1483209000 everyone. :)

Only 194 days until a nice even UNIX Timestamp

Just spent 15 minutes trying to explain Unix time and Y2K to a liberal arts major who wanted to know why 2038 is such a huge deal. It was technical, frustrating, and challenging. Kinda like debugging

Well, if your tests fails because it expects 1557525600000 instead of 1557532800000 for a date it tells you exactly: NOTHING.

Unix timestamp have their point, yet in some cases human readability is a feature. So why the fuck don't you display them not in a human readable format?

Now if you'd see:

2019-05-10T22:00:00+00:00

vs the expected

2019-05-11T00:00:00+00:00

you'd know right away that the first date is wrong by an offset of 2 hours because somebody fucked up timezones and wasn't using a UTC calculation.

So even if want your code to rely on timestamps, at least visualize your failures in a human readable way. (In most cases I argue that keeping dates as an iso string would be JUST FUCKING FINE performance-wise.)

Why do have me parse numbers? Show me the meaningful data.

Timestamps are for computers, dates are for humans.

Is this some sort of weird chocolate kind of Unix timestamp?

How to NOT handle dates!

Do not put the date to "mdy" format, today would be 050217.
Working on an intranet for some multi-billion corporation, and was wondering why events from last year were showing.

Last year's events were 28th of October, 2016, and was showing as upcoming events :)

Checked the code, and saw this. Quick fix, turned dates to UNIX timestamp, and it worked.

I wonder when the Unix epoch timestamp will surpass the human population... If it ever does

HAPPY 1510000000

semi dev related(later half)
A common and random thought I have:

A lot of units that humans use are either needlessly arbitrary or based on something weird. Like Fahrenheit. That shit is weird! 0°F is the freezing point of a water and salt solution. What a weird fucking thing to use!

But also, I like Fahrenheit more. Probably because it's what I was raised with and switching is tedious (though I'm trying. I'd like to use metric more), but also because one degree F is a smaller, more precise change. You can describe more accuracy without decimals.

On the other hand I prefer metric for length. Centimeters, and centimeters are way more precise and way less confusing than inches and .... 1/8th inches? Who the fuck decided on 1/8ths?!

Which brings me to my common thought:

If you look at a Unix timestamp, you can approximate somewhat when it happened. Knowing the current timestamp and a few reference points you can see RELATIVELY what a epoch stamp translates to. A few days ago, an hr ago, 2014ish.

This leads me to think that if we actually taught from a young age to think in epoch as a unit (not as a replacement to normal date formats but as a secondary at first) that we could just naturally read epoch time in the same manner we read dates like "28/01/2006 14:24:10 UTC"

In your brain you automatically know how old you were when that timestamp happened. What grade/job and where you lived at the time. What season it was. You know how far into the day it was, a little before lunch (or after or whatever, your time zone will vary). Now try with 1138458250. I can usually get roughly the year, and month if I really think about it, but that's it. And it takes much more effort

I'm sure there's other units we could benefit from but epoch is the one that usually brings this to mind for me.

What happens on Friday, 11 April 2262 23:47:16.855, to the Unix timestamp? It arrives to the maximum value

How do you approach generating "random" unique numbers/strings ? Exactly, when you have to be sure the generated stuff is unique overtime? Eg. as few collisions in future as possible.

Now I don't mean UUIDs but when there is a functionality that needs some length defined, symbol specific and definitely unique data, every time it does it's stuff.

TLDR STORY: Generating 8 digits long numbers so they are (deterministically - wink wink) unique is hard but Format Preserving Encryption saves the day. (for me)

FULL STORY:
I had to deal with both strings and codes today.
One was to generate shortlink word for url, luckily found a library that does exactly this. (Hashids)
BUT generating 8 digits long, somewhat random number was harder then I thought, found out on SO something like "sha256(seed) => bytes => ascii/numbers mangling" but that had a lot of collisions because of how the hash got mangled to actually output numbers and also to fit the length.
After some hours I stumbled upon Format Preserving encryption (pyffx) and man it did what I wanted and it had max 2 collisions in 100k values. Still the solution with this feels hacky af. (encrypting straddled unix timestamp with lots of decimals)

So I had this JSON thingy, where I named the property containing a datetime string "timestamp".
For some reason, JS decided to convert that into a unix timestamp int on parse. Thx for nothing.

A shower thought.

Shouldn't we all celebrate our new year according to Unix Timestamp??

Here's something that should be a standard rule for writing APIs:

When you offer a date filter for your API, the date format passed in should be a UNIX timestamp and not a literal date. For example,

Incorrect API URL format: '?start_date=2024-03-01&end_date=2024-04-01'

Correct API URL format: '?start_date=1709251200&end_date=1711929600'

For me it must be the really specific things in the PHP core that are kept for historic reasons, especially this:
"easter_date — Get Unix timestamp for midnight on Easter of a given year"