On 09/07/2020 11:30, Pavel Cisar wrote: > Mark, > > Dne 09. 07. 20 v 13:47 Mark Rotteveel napsal(a): >> >>> >>> Again, it's not correct, it's just consistent/invariant across >>> calendar. >> >> Please explain exactly which aspects are not correct according to >> you. If the goal is to produce a consistent value at a named zone, >> this is the only way to do it in a dateless type. > > The central point of our dispute is that TIME WITH TZ is pointless for > calculation, so any recalculation you do on storage/retrieval just > puts mud into waters even more. > > The TIME WITH TZ is just a wall clock at given region (24h cycle) + > information of origin where (region) the wall clock was sampled. You > can't compare times from two regions neither from the same region that > has DST or other time-shifts, as the result is meaningless. Imagine > you store time 20:35 in region that is UTC+02:00 and then you compare > it to time 23:35 in region that is UTC+08:00. What meaningful > information you will get? How conversion to UTC will help you to get > any meaningful information out of it? > > The only meaningful information stored TIME WITH TZ is the association > between wall clock and it's origin in single column. So, it should be > stored as is (the actual value when it was sampled). When I sample > 12:30 then it's 12:30 where I'm and it doesn't matter whether DST is > in effect or not. The recalculation to UTC requires use of fixed date, > so you actually remove the only one meaningful information - exact > time + origin info, because you change the time I want to store, > adding nothing useful. If I would need comparisons and calculations > that make sense, I'd use TIMESTAMP and not TIME.
Storage apart, it still requires conversions to TIMESTAMP, comparations, etc work, so a base date is anyway required. Then about storage, it of course make sense to store the UTC rebased value, as it's a -TZ type and it would make lot of sense to do it for offset-based TIME-TZ, so it should use the same storage semantics for region-based ones. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
