On 09/07/2020 12:23, Pavel Cisar wrote: > Adriano, > > Dne 09. 07. 20 v 16:39 Adriano dos Santos Fernandes napsal(a): >> >> Storage apart, it still requires conversions to TIMESTAMP, comparations, >> etc work, so a base date is anyway required. > > Conversion to TIMESTAMP without providing the exact date explicitly is > meaningless (as anomalies are numerous and result is not generally > predictable) and shouldn't be supported. If TIME WITH TZ is a wall > clock, then conversion to TIMESTAMP means that TIME is simply added to > / joined with the date part. I.e. if I want value 12:30 in region A > (taken from TIME WITH TZ) as timestamp for date 2021-06-31, then I > mean it, no time recalculations should be done and the result should > be 2021-06-31 12:30:00. I can't imagine what other return value would > be good for. > > IF TIME WITH TZ is a wall clock, then comparisons between two TIME > WITH TZ is like comparing two TIME WITHOUT TZ. Which makes sense and > could be useful, other variants IMHO does not make sense. > >> 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. > > From simple math point of view, it would make sense for offset-base TZ > as it would allow you to compare whether some time is before another > between timerzones. But practically doesn't, because comparison of two > times in UTC without date don't get meaningful values for wraps at day > boundaries (which is a lot of values). Using some deliberate date for > recalculation doesn't fix the problem, unless you actually convert > them to TIMESTAMPs for comparison itself. So doing the recalculation > to UTC at storage actually does not allow you to convert it back to > correct TIMESTAMP on comparison as the value is already skewed at day > boundary. > > As this "usefulness" is limited only to simple offset-based timezones, > it's IMHO not worth the effort as it would only cause confusion and > problems in real world use when things (zones) get messed up in data. > If one wants such comparisons, then TIMESTAMP (even casted to) should > be used. > I prefer to base implementations on standard + competitors + common sense.
So far from the standard pieces, Firebird follow standard. >From the extensions pieces, Firebird follow competitor who implement same extensions, trying to be less weird than it. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
