• @AA5B
    link
    21 year ago

    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

    • Pyro
      link
      English
      21 year ago

      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
        link
        21 year ago

        I feel your pain