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.

Temporal does have PlainDate, which is the Date primitive you're describing (by a different name, presumably to not collide with the old Date type).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is great! Thanks for sharing

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.

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)

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.

Wow! And yeah I'd imagine Healthcare requires a bit more strictness, you can't really afford an off by one day error, or sometimes even an off by one hour error.

You're absolutely right.

The calculations themselves are usually pretty easy with a few exceptions, it's just that there are TONS of them. And they all slightly depend on each other. And they change. Often.

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.

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.

> 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.

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

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.

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.

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.

This works even without timezones. If they're born even a second apart, it can so happen on different days (if they're born around midnight)

Yes, and if you ask any midwife, OB/GYN, or other person who routinely delivers babies, I'm sure you'll hear about plenty of born-on-different-days twins. One of my in-laws is a doctor who delivers babies; she has lots of stories, some of which she's restricted by HIPAA from sharing. But once a baby is born, the baby's birth date is public knowledge so she can share that info. So she often will tell her husband, "My patient is going into labor, I have to go to the hospital" without naming the patient. Then after the baby is born she'll say "Mrs. Smith's baby was born at 11 PM last night" because now it's a matter of public record who the mother was, whereas before it was protected by HIPAA. Next time I talk to her, I'll ask her if she's ever personally delivered any twins with different birthdays.

The timezones thing, of course, is just a way to have the younger twin be born "a year ahead" of the older twin by having their births be in two different timezones. Only practical way that would happen would be aboard a ship, because 1) babies born aboard an airplane would probably end up using the time zone of departure or of destination for their birth, and so twins would not be counted as being born in different time zones. And 2) any land-based transportation such as a car or a train would likely pull over (or in the case of a train, let the pregnant woman off at the nearest station) so that the woman giving birth doesn't have to do so in a moving vehicle. So a ship is the only moving vehicle where this kind of thing could likely happen, as there's no option of getting off in the middle of the ocean. It could happen while crossing time zones east-to-west, but crossing the International Date Line west-to-east makes more of an interesting thought experiment.

Yes, I've given this silly joke scenario way more thought than it really deserves. :-)

Isn't that precisely the same?

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

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.