Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".

A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.

In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.

Therefore, both you and the poster to whom you have replied are right, but you are right only when talking about future time values, while the other poster was right only when talking about past time values.

UTC or TAI are the right solution for storing past time values. Any other information is superfluous and it makes things more complicated than they should be.

Future "time" values are typically not time values. Therefore they must be stored using a different more complex data type, which contains all the information that will be necessary in the future to determine the corresponding time value.

Using the same data type to store both past time values and future time values is in most cases a serious programming mistake, which either wastes resources or is likely to cause bugs.

It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."

I must be the dumbest person in the world, then, because that's exactly what I've been doing on all my computers for 20 years (and I don't reside in Iceland).

Let's hear why you think this.

I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.

Thing is... noone resides in UTC at all.

I have set my clock on UTC on all my workstations, desktops and laptops for many decades. This has been particularly convenient on the laptops used in business trips.

For many years, when I still had some other clocks besides those included in computers or mobile phones, e.g. wall clocks or wrist watches, those were also set in UTC, thus with no change between winter and DST.

I prefer to keep in mind the current offset of my local time from UTC, and also the offsets of a couple of places where people with whom I communicate frequently are located, and to add those offsets mentally to the displayed UTC time when that happens to be necessary in order to synchronize to some external event, like a meeting or the opening hours of some place. I schedule my own activities, e.g. eating or sleeping, in UTC.

This habit was triggered decades ago by the fact that I found much more annoying the hour change of all clocks to/from DST than changing in my mind the current offset of the local time from UTC, and also by the fact that the local time does not correspond with the solar time anyway, because I an not located on the center of the time zone, so if I want to know when it is noon, I have to also keep in mind the offset of the solar time from local time, which changes when DST applies. At least with UTC, that offset remains constant.

I do not consider myself dumb :-)

On the contrary, I consider that the legal time is designed for people who are so dumb that they cannot remember that during summer they should wake up and go to work earlier than in winter, the same as their ancestors did for many millennia. To be fair, their ancestors did not use a clock for this, but they woke up depending on the rising sun, which took care of this automatically.

In an operating system especially good for multi-user remote access, why would you assume all your users are in the same timezone?

Timezone is very much a user interface issue.