Comment by OptionOfT

Comment by OptionOfT 21 hours ago

17 replies

I very much remember coding a function that split the string on their components and then rebuild them to ensure the date was created without time zone.

Sometimes a date is just a date. Your birthday is on a date, it doesn't shift by x hours because you moved to another state.

The old Outlook marked birthdays as all-day events, but stored the value with time-zone, meaning all birthdays of people whose birthday I stored in Belgium were now shifted as I moved to California...

abustamam 20 hours ago

I always found it weird when systems code dates as DateTime strings. There needs to be a different primitive for Date, which is inherently timezone-less, and DateTime, which does require a timezone.

After having a bunch of problems with dealing with Dates coded as DateTime, I've begun coding dates as a Date primitive, and wrote functions for calculation between dates ensuring that timezone never creeps its way into it. If there is ever a DateTime string in a Date column in the database, it's impossible to know what the date was supposed to be unless you know you normalized it at some point on the way up.

Then I found that a lot of DatePicker libraries, despite being in "DATE" picker mode, will still append a local timezone to its value. So I had to write a sanitizer for stripping out the TZ before sending up to the server.

That said, I am pretty excited about Temporal, it'll still make other things easier.

  • mjevans 13 hours ago

    There needs to be a difference between an Instant, an Instant at an Observed Location, and a 'Specification for constructing a date that might or might not have already passed or pass in the future'.

    E.G. in a conversation "Lets open the shop at 9am every day that it isn't closed." Is a fairly simple recurrence, with some exceptions*. If timezones change the scheduled time remains evaluated again on each day.

    • abustamam 13 hours ago

      Yeah that's a good point, and also takes into account the dreaded DST (what are this business's operating hours for example, which remains the same locally but would change in UTC)

  • mexicocitinluez 4 hours ago

    This has been a huge source of frustration in C#.

    The BCL-provided DateTime was really confusing, especially when you just needed a Date. They eventually got around to including a DateOnly, but before that happened I switched to a library called "Noda" (or Joda in Java) and after a bit of a learning curve, it made everything a lot easier to reason about.

    It has LocalDates and LocalDateTimes, as well as Instants to store UTC times. It also offers ZonedDateTimes, but I don't use those as much. I work in healthcare. And so many regulations involve strictly dates. Like, "You have 5 days to do X", not "You have 120 hours to do X", and as such, storing the time with a lot of this data can add more complexity.

eszed 21 hours ago

I mean... That's kinda how it works? More than once I've halfway forgotten birthdays of friends who live in timezones to my east, and then sent them a message saying "Happy birthday! (It still is where I am, lol)".

I'm not necessarily defending the implementation, just pointing out another way in which time is irreducibly ambiguous and cursed.

  • whiskey-one 21 hours ago

    A reminder associated with the birthday can and should be changed if I change time zones. But the birthday date didn’t change so it shouldn’t move to a different day.

    • skissane 20 hours ago

      > But the birthday date didn’t change so it shouldn’t move to a different day.

      But it does. My brother moved to the US for a few years. So we’d send him birthday wishes on the day of his birthday (Australia time), and he’d get them the day before his birthday (his time). Now he’s moved back to Australia, the same thing happens in reverse-he gets birthday wishes from his American friends the day after his birthday.

      My wife has lots of American friends on Facebook (none of whom she knows personally, all people she used to play Farmville with)-and she has them wishing her a happy birthday the day after her birthday too. Maybe she’s doing the same to them in reverse.

      • thayne 14 hours ago

        But using UTC doesn't solve that, unless the recipient of the birthday wishes is close to the prime meridian.

  • layman51 14 hours ago

    You reminded me of some riddle I had once read that was about trying to figure out how someone could be born one year later but still be older than someone born in previous year. The answer to the riddle also relies on timezones. For sure, birthdates involve time zones.

    The riddle explanation was something like: A baby is born in New York City at 12:15 AM on January 1. Thirty minutes later, another baby is born in Los Angeles, where the local time is 9:45 PM on December 31. Although the New York baby is actually older by 30 minutes, the calendar dates make it appear as though the Los Angeles baby was born first.

    • WorldMaker 14 hours ago

      The other biggest fun trick of timezone math to a riddle like that would be the International Date line where a baby born on one side of it can be born on the "day before" by calendar reckoning despite being born 30 minutes after the other side of the line.

      • rmunn 13 hours ago

        Fraternal (not identical) twins, born aboard a ship traveling west to east across the Pacific. One of them officially born January 1st, 2016. The younger-by-30-minutes twin officially born December 31st, 2015. They'll have the hardest time persuading people that they're really twins once they're grown up.

      • hdjrudni 11 hours ago

        Isn't that precisely the same?

        Doesn't even have to be the International Date line, any two timezones work.

        • rmunn 10 hours ago

          Yes, it's the same, the IDL just makes it easier for it to work, as otherwise the babies have to be born on either side of midnight while crossing the time zone line. With the IDL the birth time could be almost any time of day except for crossing over midnight and the joke would work.