Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Time zone reconciliation is a pain in the ass, it's not something I've ever been able to conceptualize easily. But it shouldn't be that all that bad for a large project if you have a unified, properly design api.
(User TimeZone) <--> (Server Time; UTC) <--> (User TimeZone)
I agree with @ergo, store everything as a unix timestamp@UTC. When accepting input, or displaying the time apply the offset relative to the user being shown the date. -
It sounds to me like your project probably used DATETIME / a readable(string) date datatype, and/or you could not assure you always have the user's when TimeZone for the inputting AND viewing. I always attach a user defined timezone to the session and fallback on the browser's/system clock. a data attrib on a <span> holding the utc unix timestamp, use js to get the offset and format content of <span> as desired
-
@rozzzly Everything you've said is right, and is how I'd do it in a greenfield project. We were retrofitting to an already jumbled code base with lots and lots of ad hoc date arithmetic.
If it was now, I would push back *strenuously* on even starting the work without first rationalising all the date logic. -
I used to work in healthcare. Dozens of huge interlacing applications. Many tens of millions of lines of code. Time zone support, or MTZ, was a dark cloud over the whole thing. We avoided it like the plague. When push came to shove, we had a special team that would swoop in and save the day. They were like the ghost busters, but for time zone support.
-
yeah the second time you have to rewrite something, you should seriously be considering abstracting it. The third time and the implementations are conflict? We'll you just started shoveling your own grave. It aggravates me how 90% of PMs and too many senior "devs" are too shortsighted.
"We've got a deadline in two months so let's continue to beat this dead horse,;if we kick enough its mangled body for long enough it will cross the finish line eventually. I call that a win." -
@lotd thanks for the computerphile video. I've been enlightened
Related Rants
My shitty boss is guilty of this.....
We called it "Project Hindenburg".
A huge planning and logistics app with hundreds of screens and dozens of interwoven subfunctions, suddenly needed to be able to support multiple time zones. Our project was to retrofit every area that touched on dates or times, to allow the user to specify, and work in, any time zone.
At this point in the story I can tell whether you have had to work with time zones in code. People who haven't are butting in with something that begins, "that should be fairly simple, you just need to..." followed by some irrelevant noise that betrays their ignorance.
People who have worked with time zones are nodding in shared pain, like fellow attendees of a survivors meeting.
You see, programmers tend to think of time zones as arithmetic; in reality, they are confusing, ambiguous, chaotic, and individual. You can't translate everything into a central time zone (eg UTC) because you lose the user's intent. For example, if you schedule a meeting for 3pm and then move it to the next day, you want it at 3pm even if the clocks have changed.
Project Hindenburg ended up using the entire development staff of the company for well over a year. It smashed our release projections to rubble, made an already tangled code base completely unmaintainable, introduced mind-bending edge case bugs that reduced staff across the company to tears (literally), and led to most of the mid-level and senior developers eventually quitting (including me).
I am @fuckfuckityfuck, and that was the story of Project Hindenburg.
undefined
wk11