• @[email protected]
    link
    fedilink
    614 days ago

    The best argument against that I’ve heard is that the date will change mid day for half the world

      • @[email protected]
        link
        fedilink
        414 days ago

        Could make some transactions and programming a bit more complex. It’s not insurmountable, but not trivial

        • @[email protected]
          link
          fedilink
          English
          314 days ago

          We already convert to UTC when doing those things across timezones. I believe starting in UTC would actually simplify it by removing that step.

    • @[email protected]
      link
      fedilink
      English
      114 days ago

      Fair point. Though it might help that the date would change, globally, at the same time. Our current setup is not flawless regarding dates.

      Currently, plotting daily events that happen before and after midnight, like sleep, is not straightforward.

      Also, anyone who stays up past midnight or works the night shift experiences this already.

      When scheduling with folks in drastically different time zones (one’s night is the other’s next-day morning) you need to account for the hour and the day. If an event is scheduled for the 2nd monday of the month it’ll be their 2nd tuesday, sometimes, or their 3rd, depending on what day the month starts on.

      It seems to reveal an issue that we use “day” to mean multiple things: the objective increment between month (or week) and hour, and the personal increment after a sleep cycle. Timezones muddle the two by adapting the former to resemble the later.