Thanks for sharing… I feel like every time i need to work with date & time, it is an annoying step in the development. What kind of dateTime string does the other interface send me, is it documented, which timezone is set for the timestamp etc.
Thankfully, I worked with some amazing DB developers early in my career and learned that timestamptz is the way to go.
This article reminds me to write about my story in Startup B. They made such a GitHub organization setup that it forced all engineers to set up filters in Gmail and mark every email from GitHub as read & archived, moving essentially every communication to Slack. It was a nightmare for async work.
This is very informative. I worked in a scheduling app startup and my boss the owner used to tell how he was responsible for few of his customer to loose money twice a year because of their patchwork for daylight related issues. They eventually rewrote whole timing engine from scratch to cleanup the legacy code.
Not specifically a DST issue, but a general date timezone issue which overlapped with DST.
Until very recently (Nov 2023, and the company is 7 years old), we had all actual production logic use UTC which is the correct for the application. But then in tests about 700 instances of using local time for test data.
We're mainly based in the UK (UTC+0) but some employees are in UTC+2 or +3.
For all those employees, and for everyone in UK for half the year, tests could not be run locally. People would run everything in CI instead. Every quarter we were wasting about 6 dev weeks in just running tests in CI.
DST is a pain. The graphs always look annoying during the harder time change. Thanks for sharing!
Thanks for sharing… I feel like every time i need to work with date & time, it is an annoying step in the development. What kind of dateTime string does the other interface send me, is it documented, which timezone is set for the timestamp etc.
So yeah - DST is another level of annoyance😅
Yeah, I don't understand why still need to think about such issues in 2024 🙃
Funny and informative article, Anton. Dates and DLS is always super confusing and annoying
Thanks for sharing!
Wow! 😅
Thankfully, I worked with some amazing DB developers early in my career and learned that timestamptz is the way to go.
This article reminds me to write about my story in Startup B. They made such a GitHub organization setup that it forced all engineers to set up filters in Gmail and mark every email from GitHub as read & archived, moving essentially every communication to Slack. It was a nightmare for async work.
I’m curious to hear that story :)
This is very informative. I worked in a scheduling app startup and my boss the owner used to tell how he was responsible for few of his customer to loose money twice a year because of their patchwork for daylight related issues. They eventually rewrote whole timing engine from scratch to cleanup the legacy code.
Thanks for sharing Avhinav. I’m curious to know what was the exact bug :)
Not specifically a DST issue, but a general date timezone issue which overlapped with DST.
Until very recently (Nov 2023, and the company is 7 years old), we had all actual production logic use UTC which is the correct for the application. But then in tests about 700 instances of using local time for test data.
We're mainly based in the UK (UTC+0) but some employees are in UTC+2 or +3.
For all those employees, and for everyone in UK for half the year, tests could not be run locally. People would run everything in CI instead. Every quarter we were wasting about 6 dev weeks in just running tests in CI.
Wow, that’s crazy. Why was the fix postponed for so long? Or it took time to understand the issue?
Well written!
Sometimes things just stay the way they are because of inertia and people lack of interest. This has to be changed for a company to grow and succeed.
Thanks! Yeah, and the older the organization is, the more such strange things exist...