I feel that this is what we should be using instead of the current illogical time system.

  • kibiz0r@midwest.social
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    edit-2
    9 months ago

    It really isn’t that simple.

    If all your system cares about is recording incoming events at a discrete time, then sure: UTC for persistence and localization for display solves all your problems.

    But if you have any concept of user-defined time ranges or periodic scheduling, you get in the weeds real quick.

    There is a difference between saying “this time tomorrow” vs. “24 hours from now”, because of DST, leap years, and leap seconds.

    Time zones (and who observes them) change over time. As does DST.

    If you allow monthly scheduling, you have to account for some days not being valid for some months and that this changes on a leap year.

    If you allow daily scheduling, you need to be aware that some hours of the day may not exist on certain days or may exist twice.

    If you poll a client device and do any datetime comparisons, you need to decide whether you care about elapsed time or calendar time.

    I worked on some code that was deployed to aircraft carriers in the Pacific. “This event already happened tomorrow” is completely possible when you cross the international date line.

    Add to all of this the fact that there are different calendars across the world, even if the change is as small as a different “first day of the week”.

    • bouh@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      3
      ·
      9 months ago

      Man I wish this was be the biggest problems I had to work on.

      All I read here is lazyness.