Pegging against "wall time" in Chile causes it's own problems. What if the meeting is with a person in "Europe/Berlin" via Skype and the appointment is in a shared calendar. How would the new Berlin time be calculated for the unfortunate Berliner after the Chilean bureaucrats have had their fun?

The Berliners should have the meeting entered in their calendar as 10 AM Chilean time. At any given moment when the meeting time must be evaluated or displayed on their own calendars, it can be converted to European time using the current time zone conversion rules.

In the example in the blog post the meeting takes place in Chile, so Berlin time is irrelevant.

But let's say you are arranging a conference call between someone in Chile and someone in Berlin. When you arrange the meeting you have to define when the meeting takes place. So you have to choose a time zone along with a time for when the meeting starts. You could choose UTC, Berlin or Santiago. But you have to choose one.

If it was done properly, the target date in the future should be based on the UTC offset it will have at that time in the future before being converted to UTC for storage. The error is to convert to UTC based on the current UTC offset instead of the "political" timezone that would take in to account proper daylight saving changes.

There are problems when dealing with timezones and daylight saving changes but the example is just a case where the implementation was too naïve.

The problem is not naive software, the problem is that you can't predict the future. There will always be dates in the future that will be impacted by some rule change that hasn't been officially enacted yet.

Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place.

The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.

Why store the UTC offset too, then? Couldn't you get that with the timezone? Then you've got the wall time for the meeting saved, and if you need to convert it to UTC for some reason, you could do it with the most current rules for the timezone.

If the offset becomes meaningless in the event of a rule change anyway, why save it when the most current rules will help you get the offset?

Good question!

It is optional to store the UTC offset. The reason to store the UTC offset is to avoid ambiguity there might be when the timezone rules do not change.

If the timezone rules don't change and you happen to be storing a datetime that is during changing from DST to non-DST, you specify which specific time you are talking about. In autumn, clocks could be set back from 3:00 to 2:00. 2:30 happens twice. When you schedule the time you can ask the user "2:30 summer time or 2:30 winter time"?

So you only use the offset for anything in rare case there is an ambiguity (usually because of going off of DST), otherwise you just ignore it. In most cases even if the rules change like in the Chile example you would ignore it as well and use the offset provided by the timezone database.

Well, it has it wrong, depending on what you are using it for. If you are putting in a calendar entry for the next predicted Lunar eclipse storing them in anything but UTC is wrong.

TAI would be better than UTC for the next Lunar eclipse in case you want to be exact to the second ;)

But yes, if you schedule the meeting in UTC, use UTC. The point is not to convert from non-UTC to UTC.

UTC just provides a labeling for TAI/TT seconds, so a count-of-UTC-seconds timestamp is identical to a count-of-TAI-seconds timestamp (assuming the same epoch). Both are different from a count-of-non-leap-UTC-seconds aka POSIX time.

You cannot know for sure how many leap seconds there will be in for instance the next 5 years. So you cannot know for sure exactly how many seconds there will elapse from now until for instance July 1st 2020 midnight UTC.

Yes, but we don't know what that labeling will be in the future.