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)

Just noticed the date format mm/dd/yy. Can we switch (or give an option to switch) to a superior to format like dd.mm.yy or iso 8601
@dfox

I need dating advice but everyone I know would just tell me to use ISO 8601...

I'm moving some old data into a new database.

It contains some dates that *should* be in ISO 8601...

This is some of the trash that I found:
01/01/70
2010-11-05T08:06:48T08:06:03.7
2007-09-13T

Moreover, it has a column which *should* contains numbers, instead it has been defined using varchar, so it contains also some wonderful 'NaN' values.

I really would like to beat the person who set up all this stuff without some basic validation policies.

[YYYY]-[MM]-[DD] or [DD]-[MM]-[YYYY]

Across all dashboards and clients we have in current company you'll find one of the above,
Every developer who ever worked on part of the system have chosen either one..

So it's a total mess,
In an attempt to standard all date formats across all our clients I setup a Slack poll,

And guess which one is winning by more than 2x votes!!
[DD]-[MM]-[YYYY] !!!

And here I thought ISO-8601 is enough reason,
But apparently not!

They say our users are more familiar with the other one,,,

It seems main problem is with the education system of this country,
That's how they were thought in schools,

So... FUCK WORLD'S STANDARDS

Okay, I know it's nothing and all that, but holy shit please either use british date standards on en_GB systems or use ISO-8601 everywhere. It's really confusing for someone from EU to read American dates..

@ Developers who don't comply to ISO 8601

I really hope you get to a really nice ice cream shop, get some amazing ice cream, only for you to trip, and fall right on top of the ice cream, ruining your favourite shirt in the process.

I've been using the Square REST API and I spent one hour thinking there was something wrong in my code until I f** found that THEY were not following OAuth 2 guidelines, which made their workflow incompatible with the OAuth lib I was using, so I had to mark an exception for Square's OAuth from the rest of my OAuths. Specifically, RFC 6749 Section 4.2.2 and 5.1.

However, after reading OAuth 2 guidelines, I became angry at THEM instead. The parameter `expires_in` should be the "lifetime in seconds" after the response. This will always be innevitably inaccurate, since we are not taking into account the latency of the response. This is, however, not a huge problem, since the shortest token lifetimes are of an hour (like f** Microsoft Active Directory, who my cron jobs have to check every ten minutes for new access tokens). Many workflows (like Microsoft, Square, and Python's oauthlib) have opted to add the `expires_at` parameter to be more precise, which marks the time in UTC. However, there's no convention about this. oauthlib and Microsoft send the time in Unix seconds, but Square does this in ISO 8601. At this point, ISO 8601 is less ambigious. Sending a raw integer seems ambiguous. For example, JavaScript interprets integer time as Unix _milliseconds_, but Python's time library interprets it as _seconds_. It's just a matter of convention, a convention that is not there yet.

Hope this all gets solved in OAuth 2.1 pleeeaasseee

ISO-8601. Much easier to deal with.

- Hey darlin, how about u n me go out for coffee on 2021-02-19?
- Hey lovely. I got an event from 2021-02-19T05:45:00Z to 2021-02-19T07:15:00Z. How about we meet at 2021-02-20T04:00:00Z?
- Perfect, there's a movie at 2021-02-20T06:10:00Z
- It's a date then

When the new junior developer suggests we switch from ISO-8601 dates to Unix time in our API.

$ git commit -am '"Fuck you, ISO 8601! NaN!" - Apple'

The CloudWatch API is an awkward piece of shit.
No convenient way to just ask for the latest value of a metric. Gotta supply a time window and hope metrics were actually reported within that window.

Oh and make sure your timestamps are in ISO 8601 or the request will fail (but the SDK does zero validation so a unit test won’t catch it of course).

Oh and you have to assign an arbitrary ID to each metric query in your request even if you don’t care about mapping the results back to the queries. And the regex for the ID is just fussy enough to be mildly irritating.

I will always fill out dates following ISO 8601 in the margins of forms that require the American format.

2018-02-27
2018-02-27
2018-02-27