Hacker News Reader

Comment by 0x0 | Hacker News Reader

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a UTC timestamp today, and the timezone rules are updated between now and then, your UTC timestamp may end up being incorrect. I guess you could have an additional "precalculated-utc-timestamp" column but regularly re-calculate this from the "yyyy-mm-dd hh:mm:ss + timezoneID" (especially when you upgrade your Olson tzdata).

View on HN

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change.

After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg.

scheduledAt: 2018-05-29T23:41:16.167 scheduledAtZone: Europe/London

Everything else in the system like created, updated, ended data is stored using UTC and transposed on the client using the user's stored time zone preference. eg.

createdAt: 2018-05-29T22:41:16.167Z

The application server your app is running on of course needs to run on Etc/UTC but with that in place (so far...touch wood) we haven't had a problem in our usage.

Yep, that's my conclusion too: storing timestamps for events in the past and up to present time - unix timestamp with optional tzid, and re-calculate local time formatting from scratch for display every time. Events in the future, do the opposite: store as yyyymmddhhiiss + tzid, and re-calculate utc from scratch for calculations every time. As a rule of thumb, at least.

Interesting. And at some point the future becomes the past and you have to switch the representation and freeze it. Not trivial.

You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.

Why would anybody schedule events in local time to happen on leap seconds?

To make sure you covered those edge cases correctly!

The best coverage is not introducing special cases where they aren’t relevant.

If it's say a scheduler for an application, you might have an activity that occurs every x seconds. At a previous job events like that were often scheduled such that x was a different prime number for each task, in order to minimize regular simultaneous executions. A system like that could easily end up with tasks running on a leap-second.

Your example isn’t scheduling in local time but in system time.

In local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.

This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous.

When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or another, somebody's 9 o'clock meeting is going to suddenly take place at 10. Having accepted that, we can push through the idealism and start working actual solutions like the one you described - have the user attach the regularly scheduled meeting time specifically to the UK or to the US.

> [..] regularly scheduled meeting time specifically to the UK or to the US

very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones.

ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"

Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."

well, technically the "funny" aspect I was talking about, was the things that happened once the meeting room booking has conflicted and two group of people clashed both claiming that their booking was more right (as opposed to "how funny this can happen" in the first place).

It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.

I think I'd resolve it by saying that any bookings made in a timezone that has changed its definition will be cancelled if the new definition causes the booking to conflict with another (including the case where two or more timezones have changed simultaneously: all involved bookings attached to changing timezones are cancelled).

"The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."

yeah, and given that in most times such change is well known in advance, the software could help dealing with it in the least disruptive way!

Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.

Also depending where you live, it might become the next calendar day in mid-afternoon. Imagine: "Want to meet up Friday?" ... "You mean tomorrow afternoon, or the morning after that?"

Everyone on UTC is really just useful for scheduling stuff internationally and just because of that, telling everyone to change their daily life, so you have it a bit easier, doesn't seem like the right plan. Additionally, timezones aren't really the big issue, it's more the changing of timezones due to DST or similar is what's causing the biggest issue. Getting rid of DST looks like a lot better solution for everyone.

The worst thing about DST is that it breaks the linearity of time, allowing for it to skip back and forth and causing all sorts of problems such as "missing" and "empty" hours.

In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.

Eh, people would keep saying 9-to-5 and post in Future-Reddit "TIL 9-to-5 jobs are called that because in the early 21st century 9am was defined as when the work-day started" or something else equally half-right.

Then someone else would reply that it was actually because Government workers traditionally finished their work day at 4:51pm.

> This kind of thing becomes a lot of fun when you're trying to schedule a regular international call

Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue.

For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10).

If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.

I've generally decided to just avoid scheduling calls for the working week before and after the DST switchover, because I never remember which of the UK and US switches first, and in which direction, and so many other people mess it up too. Of course, not everyone has that luxury of avoiding calls...

I live near a border crossing thats opening hours are set in the time zone on the other side.

My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours.

Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem.

Worst part is crossing the border is just me driving South. My longitude doesn't really change.

Well, Morocco changes its DST four times per year so that during Ramadan the night (and subsequently lunchtine) falls earlier.

    Time is an illusion. 
    Lunchtime doubly so.
        — Douglas Adams

> store the scheduled meeting time using two values; the local datetime and the desired timezone

How does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?

IMO the biggest problem isn't the how you store information or even do the date-math. The most frustrating thing is drawing out user-intent, distinguishing between two use-cases which are so similar that most users won't even know what they want.

Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged to.

A: "We'll have a global phone call to discuss this crisis in exactly X hours from now."

B: "The keynote for the convention in CityName will occur at 3pm."

Exactly that. It's like when people ask the difference between crond and atd, one fires events at a defined date/time in the future and the other fires events at a count of date/time from the present.

Another example of confusing user-intent is "last X days".

I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.

"One month from now" is horrible. Is that "30 days from now" or "same day number next month"? If the latter, then how do you handle a 31st when the next month has 30 days or fewer? (Or a 29th when the next month is February and this is not a leap year?)

This is a difficult subject.

Recurrence is especially tough to model in a database.

It depends on the context. I've programmed date logic for holiday calculation, days open for business and deadlines. I like working with dates because it's always well specified.

How about adding the number of days in the current month?

It depends on user intent.

Often the user means "same day of the week, four or five weeks from now".

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

IIRC Google uses 4am as the cuttoff. So saying "tomorrow" after that cuttoff will be the following calendar day.

> Google seems to get this right, thankfully.

Gets it right for you. If I mean today, I say today. This is especially true when I'm talking to a computer.

Both the words "today" and "tomorrow" ("morrow" being related to the word "morning") are defined in terms of the day, not whether it's before or after midnight. "Noon tomorrow" spoken at 23:55 or 0:05 refers to the same point in time (~12 hours later) in human language. I would argue that "today" is basically unassigned at night - there is no current day in scope.

Sometimes we need to use non-human language to communicate intent correctly to a computer, but we shouldn't let that redefine perfectly good and well established human language.

This is how you use today and tomorrow. It's not universal to all human language or even to English speakers. Words have different meanings depending on lots of factors including context and region.

Your definition has the same issue that mine does, just with sunrise being the time around which the meaning of tomorrow is unclear. How high does the sun have to be before "today" becomes defined and the meaning of "noon tomorrow" shifts by 24 hours? If I wake up before sunrise, does tonight refer to now or to after the next sunset?

There's a certain amount of ambiguity inherent to the English language.

Yes, there's ambiguity, but there's no reason to introduce new ambiguity where none existed before by trying to reason about these words in terms of midnight (possibly for the benefit of computers), when that was never where these words were anchored. That was the point I was trying to make.

I've always reasoned in terms of midnight because that's when the date changes. I use tomorrow to mean the next date and today to mean the current date. I'm not doing it for the sake of computers, that's just what I've always understood these words to mean.

I think using midnight as the anchor for the today/tomorrow distinction is a lot less confusing and ambiguous than having today/tomorrow not tied to the current date.

Tomorrow is tied to the morrow, so it isn't tomorrow until sunrise.

Seems like the only correct behaviour, really, would be to ask the user for clarification.

So in roughly 1200 hours then. Check.

/folks up north

Google also says that an event that took place 47 hours ago is "yesterday" which is hilariously bad.

Just print the date and time.

Normalizing temporal expressions, that is, putting human language onto a strict timeline, is a hard problem in natural language processing. There's some literature on it, which may or may not be helpful, at least in establishing the most likely intent.

Time is difficult and system design depends on the intended consumer.

For the case you propose, I read it as a "meeting" planned at a point in the future. In this case storing the start of the meeting as a bare timestamp is inappropriate design. What really should be encoded is the set of rules for identifying the proper timestamp. There was an existing standard mentioned for that which I'd use as a starting point if designing or implementing (if I chose their design) such a system.

Thank you. There seems to be some serious overdesign in the original article and a many of the follow up comments. Design should follow specific classes of user’s goals and intent, not an attempt to craft a universal solution for everyone, across all time.

Form follows function. If the concept of “10 AM on Saturday” is important to your users, model the software in line with that domain knowledge. All problems are bounded by context, and knowing the boundaries makes designs simplier and easier to manage.

> "wall clock point in time"

The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.

All of calendaring is essentially conditions, though. Your point about this being a separate concept still stands.

It's unfortunate how few libraries exist to handle abstract datetime constructs, and how frequently programming environments screw this up. The only one I know of that doesn't mince concepts is Java 8 Time [1], where points-on-timeline timestamps are clearly separate from human-centric calendrical concepts like Time-of-Day (LocalTime) and Month-Day without a year, so there's an appropriate datatype to model lots of common use-cases of date math.

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...

It depends on the application and what the customer need is.

My son’s friend in school was born on February 29. We could go through the time pedantry and claim that she is 1 year old (she is 6), or pick an arbritrary moment in time (say March 1, except for leap year) and get on with the party.

If you’re plotting a satellite course, the details matter, but many, if not most use cases require consistency over precision.

If you are dealing with physics, like a satellite course, "wall time clock" is irrelevant. Wall time clock is a human construct that is ambiguous in many edge cases, dependent on position and local politics.

Indeed, your son's friend's age is an ambiguous notion, Hence the need of a more precise contract than a simple date.

When we were building a golf tee time web site we eventually decided on this as well: always store the date-time as a string in the timezone local to the event. Convert to a date-time object in whatever timezone the user prefers (or golf tee time service APIs prefer :-P) on demand.

There is still a caveat, though. Locations can change timezone. Sometimes they do it fairly often (like every few years). You need access to a good timezone/location database that is updated regularly :-(

When we were doing this project, I was really surprised at how often we got problems. If you sell things all over the world (there are golf courses in ridiculous places), the probability that you will stumble into an anomaly is surprisingly high. Alas, this project was not a commercial success as the margins on tee times are quite small (and the tee time services you have to work with are often quite badly written). But it was quite fun to work on.

So to be absolutely correct, you store future timestamps in localtime, along with GPS coordinates of the location for the event. Then you determine the time zone of the physical locale based on a GIS lookup. Then when rendering, you offset that against the timezone of the user’s current location. I think.

I hate time.

Yep. That's exactly what we did :-) For the short time we were running the service (about a year or so) it worked great ;-)

Some timezones change twice a year. Seriously![1] A fellow engineer was responsible for the web front-end framework for dealing with time (back when we built it all here) and he spent months working through some of the strangest crap, some JS, some wierd crap humans dream up.

Good example: you, user A, are in a TZ that switches biannually - at one point in the year you lose an hour, at another you experience an hour twice. Now, another user B is also in one of these whacko places and creates a meeting (while experiencing an hour for the second time) or what-have-you for a future time where user A goes through their local groundhog hour. You have a backend server that, for legacy reasons, simply truncates TZ and goes with its own local TZ. That server is in another TZ that has an identity crisis. JS is doing dumb stuff that only JS could do. Does your brain hurt yet? I'm pretty sure that this engineer can now perceive four dimensions.

He didn't receive a bug report until we migrated to UTC. UTC made things worse, somehow. As it turns out UTC is only good for when you care about a machine doing something at some time, or when working relationally.

Store TZ (ideally location, an offset is not a TZ) along your dates. When presenting them include that information, as well as relational ("3 days, 4 hours ago at 00h15 in WA").

Time is nuts.

[1]: https://en.wikipedia.org/wiki/Daylight_saving_time

> "3 days, 4 hours ago at 00h15 in WA"

This sounds exactly like a line out of some Douglas Adams book. Which is perfectly fine as long as no one booking meetings on that app has read any of his books.

It gets even more fun if you need to answer questions like: "When this event was scheduled 6 months ago for today at 2pm, what UTC time did that represent then vs now?". Timezone rules also change. So when you're dealing with past and future you might also need the timestamp of the timestamp!

Exactly, storing both the universal time and the legal local time.

Yes, you have to periodically recompute times.

For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.

I don't think I ever heard of anyone (besides scientists) to store timestamps in TAI. Though Ada supports leap second calculations in the standard library: http://www.adaic.org/resources/add_content/standards/05rat/h...

Dealing with time well into the future is rough because of the unknown timezone changes and unknown leap seconds. There's not much you can do.

Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases.

For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And you have to store timezone, not offset to UTC -- timezones can change.

At least internally, however, dealing in TAI can be helpful[0].

Also, IIRC there's a proposal to redefine UTC as without leap seconds[1]... That scares me. Users really need wall clock time.

    The continued existence of TAI was questioned in a 2007 letter from the BIPM to the ITU-R which stated "In the case of a redefinition of UTC without leap seconds, the CCTF would consider discussing the possibility of suppressing TAI, as it would remain parallel to the continuous UTC."[16]

[0] ttps://cr.yp.to/time.html

[1] https://en.wikipedia.org/wiki/International_Atomic_Time

"That scares me. Users really need wall clock time."

Why would getting rid of leap seconds from UTC be a problem for that?

The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily.

In my view the people demanding this relationship be maintained ought to take responsibility for fixing it from their side. Speed up or slow down the Earth. Can't? Too bad then, but don't expect us to keep fiddling with the clocks.

I don't understand why you say leap seconds have nothing to do with wall clock time. Don't wall clocks include leap seconds?

Wall clocks just track UTC. Today they have leap seconds because we defined UTC to include leap seconds, tomorrow if UTC or a replacement universal time no longer has leap seconds then wall clocks won't have leap seconds.

But then people will notice a few decades later that noon in UTC-minus-leap-seconds is not noon.

But it _is_ noon.

You are probably thinking of sun transit time, "solar noon", the moment in each day when the sun appears to be "highest" in the sky. This varies of course by position on the Earth, it's how people set "noon" when they didn't need to agree with anybody more than a horse ride's distance away what the time was. So, let's say at least 200 years or more ago.

Do you know when solar noon is where you live now? No? Because it's irrelevant. Huge numbers of people live in places where the solar noon changes by an entire hour twice a year for no sensible reason. Does this cause a huge problem? No, there's a slightly elevated rate of road accidents and things like that, but nothing major. A few seconds per decade is _nothing_.

What's noon? Depends on who defines it. This is the problem with time.

Times in the future being problematic reminds me of the quote attributed to Neils Bohr:

"it is very difficult to predict — especially the future."

There's "Google time", their approach to leap seconds. 12 hours before a leap second, Google's version of UTC time starts running slightly slow, so that it loses a second over the next 24 hours.[1]

Some Google database systems rely on tight time synchronization to order update events, so they had to have a global monotonic clock.

[1] https://developers.google.com/time/smear

That's what we do in the Cyrus IMAP scheduler for future alarms. We set the trigger at most 30 days in the future, and at that point it will re-calculate when the alarm should fire. Using the tz database at the time each time around.

Of course, calendar events in icalendar have the tzdata stored along with them, in theory, so they should never change unless your client updates them. Which leads to its own world of fun.

Depends. Some things need to happen N seconds from now. Other things (usually things involving humans) need to happen on a day that those humans will look at their calendars and say "oh, it's [that day]! Better do [that thing]!"

The comment above was referring to the second kind, but it's true that it englobed too much

I might not be understanding your scenario correctly, but isn't it stated that UTC has 00:00 offset and should be stored that way? You would then add an offset based on current tzdata for that timezone string which would make it dynamic and accurate for the situation you described.

There's two distinct things at play here - storing times in the past and present, and times in the future.

For the past and present, UTC is fine, and a source timezone if necessary. To track the exact instant when something happened to me, just storing UTC is fine. If I want to know what where the hands on my clock were when that happened, you also store which clock I was using separately (timezone), but this is optional and doesn't prevent accuracy.

For future times, relating to humans, like on a calendar, there's a very important distinction - I want to set appointment when my clock shows a certain time, irrespective of what the timezone rules (Daylight saving time rules can change) are at that point. Here, storing the UTC time for my appointment according to today's rules is a problem - you must simply store what I expect to see on the clock and apply the timezone rules lazily at the last possible minute.

Actually the meaning of a date like:

2018-05-26T13:45:21+02:00

Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from:

2043-02-12T11:15:16+02:00

You won’t be able to, because then you have to account for leap seconds, etc.

Also “next Tuesday” does have to take into account the time zone as you may need to deal with daylight saving time.

However “next Tuesday” is not a date-time, but a relative difference from where you are now and by pre-calculating you lose information.

Also relevant, in such cases storing the time zone doesn’t help because the user himself might travel and next Tuesday at 7:00 can remain the same, no matter what time zone you’re talking about.

It depends. It could be a meeting in a particular city at 4pm local time. A "+02:00" or "-05:00" specifier is insufficient because the government of the particular city/country might change the time zone rules between now and when the event is to occur. So you really need to store "2018-08-01 16:00:00 America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01 they decided to go for "-05:30".

Indeed. There's a concept of relative physical time

a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter.

and relative calendar time

b) "I'll meet you 15:00 next monday".

Both of which are valid.

What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all?

I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though.

[1] Calender-type application is actually pretty niche IME. Opinion may vary.

The meaning of “2018-05-26T13:45:21+02:00” may not change, but if 2018-05-26 rolls around and the restaurant where you have a lunch reservation at 13:45 local time is no longer in the +02:00 time zone, it’s not the same time that your reservation is scheduled for anymore.

>Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change,

It will respective to the local time though if a state decides to stop honoring DST or changes TZ.

I once ran across a book of changes over time to local time zones, I believe for historical research. It was the size of a phone book.

Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages.

Covers probably well over 100K locations each with its own history of timekeeping.

The meaning of the date will not change compared to the UTC absolute coordinates, but usually users care only about their local time. If you set an alarm to wake you up at 8:00, you expect it to ring at 8am your time every day. What if in future user's local time zone gets changed - say if daylight savings are abandoned, as many countries consider doing - The user might not be in +2 offset anymore and when you convert it to the local time the alarm will ring at 7am or 9am instead of 8:00. It's definitely not what user would expect.

what the user expect is of course completely different if there’s not one but several users, or several referentials.

Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event)

Time is hard.

But users want wall clock time. That you stored 2018-05-26T13:45:21+02:00 is irrelevant. The user wants that time to change if the original timezone's definition changes.

So you really need to store {datetime, timezone_name}.

It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.

If you had UTC and the original timezone code, you could run a job that updates future timestamps according to timezone changes. This might keep things cleaner.

There is a solution for this, Unix timestamps.

Looks like someone didn't read the article :) If you normalize to UTC for some future date with a timezone in Lower Left Elbonia Standard Time (GMT+7:42), and the Elbonian Revolutionary Army successfully form an overnight junta, retroactively declaring the country's timezone to be Free Peoples' Elbonia Revolutionary Time (GMT-12:00), suddenly your DB rows make no sense whatsoever.

The absolute point in time relied on future knowledge that did not yet exist, that invalidated any previous estimate of when it would occur. An external timezone reference (the Olsen DB) must be continually updated and separately referenced

That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.

How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.

From the user's perspective it is the same appointment. They think they have an appointment at 3:00 PM on Thursday. If there's a timezone change, and you just stored an integer, then from the user's perspective the meeting changed from 3:00 PM to 2:00 PM.

Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.

Your integer is wrong because it was computed by translating from the current offset of the timezone. What we are saying is that the timezone definition might change in the future (ex. Government no longer honor DST). At that point when you translate back your timestamp into local time it no longer matches the original schedule that the user set.

But the integer stays the same. That's the main point here. Everything else is just converting it to local time. Sure timezones might change that.

This is exactly wrong I think:

If the timezone changes under my feet the unix timestamp might suddenly not refer to my birtday anymore.

Watching people struggle with this is frustrating.

Also I currently work with frontend and while it is no surprise that JavaScript has messed this up badly [0] it surprised me when I realised that a certain large UI framework had a) messed it up b) didn't realize it and tried to close it down when people tried to help.

[0]: they copied Javas first broken Date handling and suddenly they were stuck with it IIRC.

Edit: heh, double-ninjaed

Reply on news.ycombinator.com