this post was submitted on 18 Nov 2023
88 points (96.8% liked)

Programming

17366 readers
280 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] hascat@programming.dev 4 points 11 months ago (1 children)

What do you mean by UTC only?

[–] onlinepersona@programming.dev 1 points 11 months ago (2 children)
[–] emptiestplace@lemmy.ml 5 points 11 months ago (1 children)
[–] onlinepersona@programming.dev 3 points 11 months ago (1 children)
[–] Pyroglyph@lemmy.world 5 points 11 months ago (1 children)

I think what they meant is requiring that only UTC time should be in the database. This prevents ambiguity when pulling dates/times out as with many poorly designed systems it's not possible to know whether a date represents UTC time or local time.

At my work we store local time in our database and I hate it. We only serve customers in our country, which only has one time zone, so that's fine for now. But we've definitely made it harder for ourselves to expand if we ever wanted to.

[–] AA5B@lemmy.world 2 points 11 months ago (1 children)

Better yet, why are you not using a Date type? That’s very precisely defined, more scalable, and plenty of functionality for doing math or converting among time zones. You don’t have to care what time zone you’re in, and can give people the answer in any time zone

[–] Pyroglyph@lemmy.world 2 points 11 months ago (1 children)

I get the advantage, and if I could change our schema with a click of my fingers I would, but it's not that easy. We do use the native date type in our schema, but the dates we store in there are in local time. It's bad, I know. It was originally written by a couple of people about 15 years ago, so software standards were a lot more lax back then.

We already have many customers with lots of data that are currently using this product, so it's unfortunately non-trivial to fix all of their data with the current systems we have in place.

We developers often want to fix so many things but we're often told what to do based on what the business cares more about, rather than what we actually want to fix. That's why we always end up building shit on top of shit, because the business doesn't want to pay us to rewrite 15-20 years worth of legacy code despite in doing so it would make the product an order of magnitude better in every conceivable way.

[–] AA5B@lemmy.world 2 points 11 months ago

I feel your pain

[–] UFODivebomb@programming.dev 4 points 11 months ago

That is a somewhat tongue in cheek comment. I think time zones are silly and people could easily account for the differences of what a particular time point means for them at their location. More realistically, UTC should be the only way a time stamp is stored.