> Frankfurt on July 26th 2029 at 1pm

That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do that is to store the time zone in a 100% normalized, unambiguous way that is then transformed into whatever matches the user's preferences as part of the presentation logic.

In the same way, place names are localized. The French would spell Frankfurt as Francfort, for example. Location should be a separate field. And it implies nothing about the locale that should be used for presenting the timestamp or the timezone that should be used. Because Frankfurt is a rather international town and some might prefer MM DD YY instead of DD MM YYYY. Not to mention the use of am/pm vs. 24 hour time. And of course it has a big airport that people use to travel to pretty much all time zones on the planet. Hard coding all that in a timestamp is a mistake. Because now you need needlessly complex parsing logic and transformation logic to fix that mistake. Which is what this article is about.

▲

ttiurani 4 days ago | parent [-]

> That's a localized date and time.

Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone.

E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the meeting.

So it's not about presentation of the timestamp, it's that the timestamp does not match what the user meant.

> In the same way, place names are localized.

I beg to disagree. All spellings refer to the same phyysical place, but you can't guarantee my example timestamp description and a simple ISO time representation without a geolocation will refer to the same singular point in time.

▲

skrebbel 4 days ago | parent | next [-]

I agree with the gist of your comment but I think you’re using the wrong words.

A time zone, as the name implies, is a zone, a place. The most common way to indicate a timezone is a continent+city combo that is both politically and geographically close, so it’s unlikely to change. Therefore, I very much know the timezone of Frankfurt, both today and in the reasonably close future, namely “Europe/Berlin”.

You’re talking about the timezone offset. You’re right, don’t store that for future local dates. Store the timezone.

(Or just the exact location, but then you need a way to map location -> offset if you ever want to do time math on it, and the IANA Continent/City format strikes a nice pragmatic balance there)

▲

ttiurani 4 days ago | parent [-]

Well, not really. :) Timezones are the whole area that has the same time. So "Europe/Berlin" and "Europe/Rome" right now can be used in user-facing help texts to make the timezone understandable, but those cities might not be in the help text in the future. That's because:

"Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." (https://en.m.wikipedia.org/wiki/Time_zone)

So the offset is the timezone.

That's why I stand with my original point: if you want to support "clock on the wall" future dates, a geolocation is needed. And given that Germany was two countries in the recent past and Frankfurt and Berlin were in different countries, I wouldn't solve this by picking a city from the help text that's currently closest to the timezone, but instead use the actual geolocation of the event.

P.s. All this is, of course, for 99.99% of the cases a complete overkill, and as said, I haven't had issues in using unix epoch for all dates. But just wanted to say that timestamps aren't as simple as I felt was suggested in the first comment.

	▲	fmajid 3 days ago \| parent \| next [-]
		The offset changes twice a year in many countries due to the misbegotten Daylight Saving Time. What's worse, governments can and do change the dates of the transition so you need something like the Olson (RIP) database to do retroactive time calculations. The US changed its DST dates in 2007, for instance.
	▲	skrebbel 4 days ago \| parent \| prev \| next [-]
		The way I understand it, Continent/City names aren't for pretty dropdowns or help texts (in fact, I'd wager they're kinda meh for that). They're the least bad way people have come up with to store and communicate timezones with future local dates, that doesn't require online geolocation. You're right that geolocation is the best. But offsets aren't a close second, like I feel your comments suggest - they're just a bad idea. To suggest that a timezone "is" an offset, while technically correct if you disregard future changes, is actively harmful to helping people write code with fewer timezone bugs. Use IANA Continent/City names. They're great, all proper datetime libs support them, your OS supports them, they're reasonably human readable and completely machine readable. They're better for storage than offsets (or terrible future-incompatible terms like CET) in every way. Really the entire timezone debacle can IMO be summarized as: - for datetimes in the past, store UTC. convert from/to local in the UI; just assume the system/browser locale is the one unless you know otherwise. - for global datetimes in the future, eg comet passings and the likes, same thing. - for local datetimes in the future, at some "wall clock time in a place", store localtime + an IANA Continent/City combo, and keep your servers' tzdata files reasonably updated. It never makes sense to store or communicate offsets. It hardly ever makes sense to do geolocation unless you think you think the chance that Berlin moves to a different country than Frankfurt is bigger than the chance that you lose access to up-to-date geolocation information. Note that the above implies that the option for ISO date strings to include offsets (or words like "CET") is, IMO, nearly always the wrong choice. For past dates (ie 99.9% of dates stored by computer systems) just use UTC, and for future dates, IANA timezone names are strictly better.
	▲	GoblinSlayer 4 days ago \| parent \| prev [-]
		Or in 2027 the Sith Empire could conquer Earth and install imperial time system. Good luck with your timestamps. Just make your scheduler as a walled garden SaaS - no need to exchange timestamps.

▲

Arrowmaster 4 days ago | parent | prev [-]

Ah I have the perfect solution. Let's add GPS coordinates to datetime stamps!

Please put the pitchfork away it was only a joke. (Until someone actually does this because it makes a twisted sort of sense)

	▲	fmajid 3 days ago \| parent [-]
		The good thing about this proposal is that GPS coordinates include altitude, so you could use them to correct for gravitational time dilation due to General Relativity.