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 9 hours ago | parent | next [-]

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.

▲

cpmsmith 7 hours ago | parent | next [-]

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

	▲	abustamam an hour ago \| parent [-]
		This is great! Thanks for sharing

▲

mjevans 2 hours ago | parent | prev [-]

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 an hour ago \| parent [-]
		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)

▲

eszed 10 hours ago | parent | prev [-]

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.

▲

layman51 3 hours ago | parent | next [-]

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 3 hours ago | parent [-]

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.

▲

hdjrudni 13 minutes ago | parent | next [-]

Isn't that precisely the same?

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

▲

rmunn 2 hours ago | parent | prev [-]

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 minutes ago \| parent [-]
		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)

▲

whiskey-one 10 hours ago | parent | prev [-]

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 9 hours ago | parent [-]

> 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 3 hours ago \| parent [-]
		But using UTC doesn't solve that, unless the recipient of the birthday wishes is close to the prime meridian.