2.0 KiB
+++ title = "Things I Learnt The Hard Way - Always Use Timezones With Your Dates" date = 2019-07-01
[taxonomies] tags = ["books", "things i learnt", "dates", "timezones"] +++
No matter if the date you're receiving is in your local timezone and you'll display it in your timezone, sooner or later, the fact that you ignored there was a timezone behind that date will hurt you.
(Note: Most of this post when I say "date" you can think of "date and time", although the date should also be "timezone aware".)
At some point of my professional life, ignoring timezones was easy: You just pick the date, throw in the database, then read it back and everybody was happy.
But things are not like this anymore. People will access your site from far away locations, the source of the date may not be in the same timezone of your system, your system may be running in a completely different timezone of your dev machine (it's pretty common to run things in our machines in the local timezone but the production system will run in UTC), the display may be a complete different timezone than your production and dev machine and so on.
So always carry the timezone with the data. Find modules/classes that support dates with timezones (a.k.a. make things timezone aware), capture the timezone as soon as possible and carry it around in all operations. Modules/classes that don't support timezones for dates/times should, as soon as possible, removed from the system.
Any developers a bit more seasoned -- and by "seasoned" I meant "Had to deal with times before" -- will probably claim "Hey, this is obvious!" And I'd have to agree. But it's annoying how many times I got bitten by some stupid bug 'cause we decided that "well, everything is in the same timezone, so it's all good".
{{ chapters(prev_chapter_link="/books/things-i-learnt/start-stupid", prev_chapter_title="Start Stupid", next_chapter_link="/books/things-i-learnt/use-utf8", next_chapter_title="Always Use UTF-8 For Your Strings") }}