3 ms·

Which is, store the original intent, and re-intrepret the cached-unified-value any time there is knowledge-context change. Might become bitemporal.

• adrian_b 5y ago
  The problem here is a confusion between 2 different data types and attempting to use one type instead of the other correct type, which is a trivial programming mistake. A future time moment may be a true time, known exactly, which must be stored as an UTC time. Otherwise, it may be an event defined in the official time of some place. This must be a distinct data type, because as mentioned in the article, the real time that corresponds to it cannot be known in advance, because the legislation defining the official time may change before the event takes place. Obviously this second data type must store the complete information that determines the event time, i.e. both the official local time and the place, so that, a short time before the event, the correct conversion to real time, i.e. UTC, can be done, and then the different local times for each participant may be computed, to be displayed in their schedules. Of course, for displaying, an estimated UTC time for the event can be computed since the beginning, but it should be updated when the event approaches. The only problem here is when you fail to recognize that the "time" for a future event that is scheduled in local time is not a time, and you attempt to store it using the wrong data type. Also one must keep in mind that for this second data type, for future events scheduled in local time, no arithmetic operations can be defined, like the difference between two times. The only operation that can be defined for this data type is conversion to and from UTC.
• stingraycharles 5y ago
  I don’t think this is bitemporal, though: they’re two different “views” of the same time.