On 24/04/2019 03:53, Jiří Činčura wrote: >> That is not a problem. The ambiguity exists only when transforming a >> timestamp+TZ (as one sees it) to UTC. After parse the literal, it's >> always in UTC+TZ. >> >> UTC+TZ is always transformed to a valid displayable timestamp+TZ. > That is a BIG problem. Because the TZ rules can change. So i.e. what was once > in DST is no longer in DST. > > Your way kind of works for past dates (up until some point in past where we > have reliable TZ data, but that's IMO fine), but fails badly for future dates > (or near past days). > There is trade-offs and the thing cannot work 100% correct for all cases in any approach.
In the way you said there are these problems when rules changes: - The times will not change on the local time but will change relative to GMT - and you do not known if in that specific column that is the desired behavior. If a meeting (not in db, but in real life) is schedule in GMT, the local time *should change*, and not stay identical in the local time. - A stayed local time will be moved in regard to GMT, and that could break unique constraints, as 01:00 +01 is equal to 02:00 +02 as both are 00:00 +00. On the other way, the approach I choose: - Do not break unique constraints - Stored GMT data is the single source of truth I'm not against tools to help one fix timestamps after rule change, but definitively that should be tools, not the storage of values that should be changed. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
