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.
regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
