Hacker News Reader

Comment by dtech | Hacker News Reader

You lose context. Say you have 2100-01-01T10:00:00 in PST. That's 4102452000, so you store it.

A few decades later, timezones are changed. PST should add 30 minutes, all others stay the same. You only have 4102452000, what should you convert it into? You lost the time zone information, so you can't make the correct decision.

View on HN

Changes to timezone changes can be quite abrupt too, this one was announced about 3 months before it took effect. Developers scramble to update software.

https://www.bbc.com/news/blogs-news-from-elsewhere-28423647

https://mm.icann.org/pipermail/tz/2014-July/021104.html

if you need context, e.g. location, you can still save it in another field and you will be able to correctly display localized time at any point given the universal timestamp and the current location. Or you can save properly localized and tz-aware time, I just find timestamps safer from pitfalls.

It's not about localization, it's about correctness. you need both the timestamp and tz if you care about the future local date and time.

You seem to make a contradicting statement here with what you wrote in the sibling comment, no? timezone information are influenced by political means, whereas localization (lat/long) information is not. UTC timestamp + localization seem more correct to me.

The semantics of "time X at point Y" are different from "time X in time zone Z". Sometimes the former may indeed be what you want, but it's uncommon for the user to be providing precise location information for a point in time far in the future. If you're told "time X, Eastern standard time", then the semantically correct thing to do is to not guess a point in space, but instead preserve the time zone as provided.

This line of thinking is how we end up with nonsensical UX like having to select "America/Los Angeles" to get US Pacific time. There are many use cases for datetimes and timezones, not all of them need a location and in some cases it's incorrect or misleading to include a location. You could certainly use a UTC timestamp and coordinates in your application but that doesn't work for many other use cases.

> if you need context, e.g. location, you can still save it in another field

No. Say I have a database with a bunch of timestamps for future events. I calculate the time of those events with my current idea of local time (because my customer or because legal requirements require me to do something at a specific local time), convert to GMT, and store as a timestamp in my database.

In 2024, California decides to no longer observe Daylight Savings Time. All of those current timestamps no longer happen at the proper time in the newer version of America/Los_Angeles.

So there's a big pitfall here, in that the relation between localized time and UTC timestamp changes.

Sure, you and others like you make pretty valid points. I believe we are talking about different use cases, hence the confusion. I was thinking of my most common use case of archiving events, usually experimental data, with a non ambiguous time reference.

If you need to schedule future events it gets obviously a lot more complicated, you don't need a timestamp you need local time and you need it to be robust to future changes in timezones, DSTs, politics.

Basically, it's important to recognize what you're actually measuring/capturing and store something maximally equivalent to that. Conversions may render figuring things out later impossible or very difficult.

If you care about a past moment in time as reported by GPS or a computer clock-- use a UTC timestamp.

If you care about a future time delineated by a precise interval from now-- use a UTC timestamp.

If you care about a future time expected to be delineated in a specific time zone, use a timestamp in local time and note the zone.

If you care about a future time in a customer's time zone no matter where they may be, store the time in an unspecified local time and the customer for whom the time applies. Etc.

Your example is valid and replies are ill-informed. There is a difference between a "date" and "time interval". Timestamps are good for storing intervals, but if you need to plan something on a _date_, you need to store the date. This means you care not about specific number of seconds having passed since now, but about what calendar (and the clock) is saying when the event has to happen.

Example: nobody cares if a concert planned on November 19, 2024 at 19:00 in Honolulu starts in 12345600 seconds or 12349200 seconds since now. But everyone cares that everone's calendars and watches are in sync by that time and show specifically that date and that time, regardless of how many times people switched DST or timezones in the years in-between.

Just store the time stamp and time zone separately and update the time stamp to reflect any changes to a time zone's offset (if that actually happens)...

It takes a bit of housekeeping, but isn't especially difficult.

As far as i'm aware, you should only store the location next to the timestamp and let the IANA[1] do the maintenance of the tz database. Please avoid the housekeeping on your side.

[1] https://www.iana.org/time-zones

That works, but then you're working with timestamp+tz, not just timestamp. You lose a fair bit of the simplicity compared to e.g. ISO8601 strings.

> if that actually happens

The IANA time zone database [1] is updated several times a year, it happens all the time

[1] https://www.iana.org/time-zones

It actually is especially difficult at scale for non-trivial applications. Large databases won't be able to atomically change every instance which may lead to very frustrating bugs where collisions cannot be allowed. For example, on a calendar app. I agree with dtech, if you're storing in the future don't use a timestamp unless the input value is specifically intended to be timezone unaware, which is typically only useful for short term things like control systems or alarms. For longterm human uses a datetime+timezone field or an ISO datetime+timezone string is safer.

> Just store the time stamp and time zone separately and update the time stamp to reflect any changes to a time zone's offset

Thus reinventing zoned datetimes badly

> if that actually happens

It happens literally all the time, sometimes with very little heads up e.g. the decision to apply DST or not can be take mere weeks before it actually occurs[0], and something as impactful as an entire calendar day disappearing can happen with 6 months notice[1].

[0] https://egyptindependent.com/egypts-hasty-goodbye-daylight-s..., https://codeofmatt.com/time-zone-chaos-inevitable-in-egypt/

[1] https://www.theguardian.com/world/2011/dec/30/samoa-loses-da...

Thanks for this - I've learned something new today. I did not realise timezone updates were so frequent.

I do find that having the timestamp at hand makes math easier in a lot of the use cases I've come across. I wonder if there is an easy hybrid solution where you can capture timezone info, timestamp info and have it adjust without a full DB update, even if timezone offsets change. Maybe a mapping table of some kind, with versioned timezone codes.

Do note that this is an issue for future events.

For past events, you can store timestamps, it doesn't matter, the mapping is known and fixed.

Reply on news.ycombinator.com