On 24/04/2019 09:57, Jiří Činčura wrote: >> 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. > What I'm trying to say, that simply storing in UTC+TZ is not enough, because > at the minimum you need at least (1) the TZ data version so you can do the > conversion yourself - either fixing "local" time or UTC time. But you can't > get that information now.
You have it. It's the version before you upgrade the table. Honestly, I think it does not make sense to have it stored within the values. It will then need to be informed by API user or get automatically. And even automatically, semantics would be extremely unclear when moving values to/from variables. Also, when updating the rules every column you validated should be updated, and the ones not validated will stay with a (very) old release number. That in practice is a complexity nobody will use in this way. Data should be validated/fixed when new rules are installed. So IMO the problem is letting OS (or some shared component) be the master of time zones rules instead of Firebird engine having its own controlled table. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
