loading...
Cover image for Dates are hard folks

Dates are hard folks

nickytonline profile image Nick Taylor (he/him) ・1 min read

I saw this posted yesterday and thought it would be fun to discuss. "Scientists rename human genes to stop Microsoft Excel from misreading them as dates".

Dates can be hard when handling them in code. There's a reason people reach for date libraries. 😉

Anyone have some great stories about working with dates?

Discussion

markdown guide
 

Sure, this video is one of my favs regarding time!

 

I love this video. Another great thing I like to link any time someone mentions timezones is this article: UTC is Enough for Everyone, Right?. It's quite long but absolutely hilarious and extremely informative.

 

What a timeless piece.

I enjoyed every single word if it, the frustrations from common pitfalls that arise in every aspect of time/dates/zones/formats...

Oh, it hits home so well it's sad and funny at the same time.

 

😂 That link is hilarious and definitely worth the long read!

 
 

Back when Flash/Flex was still a thing, user's used to submit date objects in forms. That time the rpc protocol used was something called BlazeDS.

What this BlazeDS used to do, is serialize the date with the timezone information and then send it over to the server (So you select 2020-02-03 as a date, it will send 2020-02-03 02:00am). Then the server would deserialize that date in it's timezone (so 2020-02-03 02:00am back to 2020-02-03 00:00).

All fine and well, because this was for a backoffice application. Until the day our software got deployed in a multinational company sitting between two timezones. So client sends a date in a +2 timezone, and the server sits in a +1 timezone.

Because two different timezones were being used for serialization/deserialization on on the client/server, the incorrect dates were always being used in ALL screens (50 or so). Took a good day or two for me to figure it out.

TL;DR; Always send dates over as strings and as UTC time.

 

even better send them as a number representing milliseconds

 

it depends on the language you use. I wouldn't recommend this for Go specifically.

 

User: Why does it show this event happened on a different date when I know it happened on X
Me: Because the event is recorded according to their timezone; which being close to midnight here, the time difference means they are on a different date.
User: Shouldn't it still show the same date though? It happened on X. I thought timezones only change the time.
Me: No... that's not how dates work...

 

Not a story so much as a general frustration - I find myself having to convert Dates in Excel to Unix timestamps an awkward amount and Excel's base date being 1/0/1900 and UNIX being 1/1/1970 always causes trouble 😅

 

My husband works in information security for a trading firm which means he has to schedule software updates for the company. For one update, he scheduled it for what he thought was UTC-6, but it was actually UTC. There is a video from the security cameras of him sprinting across the office when he realized his error to unplug all the servers to prevent them from running the update in the middle of the workday.

 
 

With the Java Date formatter "YYYY" and "yyyy" have a very slight difference.
YYYY will give you the year belonging to the current week (whatever that means and is useful for). So sometimes around the end of the year things break.
So, the 31st of December 2020. That week technically belongs to the year 2021, so YYYY was returning 31st of December 2021 from our API while the database was correctly storing it as 31st of December 2020.

ALWAYS use 'yyyy'

 

The 'YYYY' format is for week number dates (today is 2020-W32-5 per the ISO 8601 week date system). Week number dates are used a lot in manufacturing (or at least, the year and week number is, not the weekday as much) because that makes it easier to trace a given batch of products to a particular shift that was responsible for producing or checking them.

 

Dates are indeed hard especially when they are timezones involved, I had to deal with Timesheets at once and calculations went all well but the last for monthly calculations was on the 26th and timesheets would just go insane especially those on a different timezone. It was a nightmare for the first months.

 

Leap years and time shifts everywhere! They're out to get you. Run!

 

hhhh im actually right now working on a project, (adding some features and the feature is all about dates and times ! its actually sooo fun really thanks to momentjs :)

 

I just started out with a random thought of building an age calculator from the birthday and it took me like almost 5 hours. It was seriously frustrating to work with dates.

 

The only reason I clicked this is because my first thought was that dates referring to mating.
Now those are harder than the ones in, let's say, Java.

 
 

I got the courage to put myself back out "on the market" after a toxic relationship by doing competitor research for a dating app startup I almost co-founded.

...Oh, THOSE dates... Nah, those suck.