Hacker News Reader

Comment by layer8 | Hacker News Reader

The problem is that we don’t know what the timezone identifiers for hypothetical future timezones will be. Meaning, there would be no automated way to associate those future-date-time values with the correct timezone once the new timezone is added to the tz database.

One could imagine using geo coordinates or similar, but the mapping from those to timezones (or from/to zip codes or area codes) is already not precisely defined.

If you use city names, those might also be split/merged (Berlin) or renamed (Constantinopel).

View on HN

If you use coordinates, make sure to take into account continental drift. You could use a plate-local coordinate system (e.g. British National Grid for Great Britain) so you only need to take into account deformation.

There is actually a good read on this at https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move

What about storing current geo coordinates and a timestamp of when they were recorded? I feel like that should be enough for a theoretical future system to adjust mapping for continental drift.

The problem with geo coordinates is reverse mapping them back into political owners, so you can then determine current timezone policy.

There's 4 things at play here:

   - Coordinate location on the planet
   - Identifier for that location
   - Political entity for that location
   - Current timezone policy

Of those, coordinates are the only thing that doesn't change over time (for the spans we're talking about).

But are also a pain in the ass to use. F.ex. I'm sure someone on HN has the lat long for London memorized, but I don't.

London is perhaps the only major city where you could be expected to know one of these coordinates. It's defined to have longitude 0.

I suggest giving date and time in the form of phase/frequency references to nearby pulsars. That should guarantee stability for a few million years.

Especially assuming an increase in computing intelligence in that time.

Europe as a whole is too. IIRC there's a set of points around the periphery of the continent that are measured to centimeter accuracy.

This whole discussion highlights the point that timezones etc. are relatively arbitrary. Often the "time" isn't as important as the events that take place at a given time. E.g. 6pm is a reasonable dinner time on the west coast of the US, but dinner doesn't start for many people in Buenos Aires, Argentina until after 8pm [0].

[0] https://turismo.buenosaires.gob.ar/en/article/what-where-and...

>there would be no automated way to associate those future-date-time values with the correct timezone

You could develop a way to specify a location and indicate that you mean 'local time' at that location.

And then they change the calendar. (It has already happened in several regions when changing from Julian to Gregorian calendar. You don't know what calendar will be used at that region in the future)

What time zone people use at a given location is not even a function of geographical location; you plausibly also need to know language, culture, political affiliation, and/or employment status.

What is the issue with taking in a time format which people use at the current time, then convert it to coordinates + unix timestamp for definitive time and using it instead?

The zone database recently had a city spelling change on Kiev to Kyiv

change or adding same entry with the name of city changed ?

Coz change like that could fuck some shit up...

A link was added from "Europe/Kiev" to "Europe/Kyiv" in the included-by-default backward file [0], so that any user that doesn't exclude that file will simply treat the old name as an alias for the new name.

[0] https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064a...

There are a few kinds of entry in the tz database. Europe/Kiev is now a Link entry to Europe/Kyiv which is a Canonical entry. Europe/Kiev used to be a canonical entry. What's interesting is there's a lot of thoughtful commentary about changing the name and handling the annexation of Crimea long before Russia invaded Ukraine

For example: https://data.iana.org/time-zones/tzdb-2020d/europe (search for Kiev for the specific part; it's a very long file)

I love reading the tz file every now and then, it contains the ultimate time and time zone nerdery.

How is it not precisely defined? Lat/long to timezone ought to work... timezones have precise boundaries that cover the whole earth, no?

> timezones have precise boundaries that cover the whole earth, no?

Not only is that not true, but there are places on the earth where one country may think the timezone is X, but in another country it is illegal to claim that the timezone is X.

This happens most notably with China, which defines the entire country to be in a single timezone, and is engaged in multiple border disputes.

Similarly for many disputed territories in Antarctica, with the added fun of "the south pole region is special". But of course that is a very marginal topic.

I maintain https://github.com/photostructure/tz-lookup which does this task.

*Every single time* I update the tz source file some arbitrary set of zone names and offsets change. Look at the churn and enjoy the schadenfreude: https://github.com/photostructure/tz-lookup/commits/main/tes...

A triple (Lat/Lon/UTC Date) <-> TimeZone at the very least.

Time zones are political | * social* especially in the twilight zone between two otherwise well defined zones.

If a country is mostly in TimeZone X then often an extrusion that goes well into TimeZone Y will remain with clocks aligned to TZ-X unless some local political change is made (to be more or less sensible).

See (current TimeZone Map):

https://www.timeanddate.com/time/map/

and note that cities have changed time zones (not daylight savings changes, actual changes to core time zone) in the past and will almostly certainly do so again in the future.

The changing of zones isn't a problem, that's why we're using lat/lon, but if the nearby countries can't agree on what time it is...that's an issue.

Reply on news.ycombinator.com