On 08/07/2020 14:00, Pavel Cisar wrote:
TIME WITH TIMEZONE is pointless. It sort off works for "naive" TZ that
does not have things like summer time and other time shifts based on
date. The pytz library does not even allow you to create time with
such tz. The dateutil does, but the usability is near zero, because
you can't get offset, tz name etc from it (so also the calculations
are crewed).
I have also been struggling to find a use for TIME WITH TIME ZONE.
For example, if you are dealing with "Wall clock time" (e.g. the opening
time of a shop) then you really want to have the time zone encoded
separately. This is because, if you want know (e.g.) in London, if a
shop in (e.g.) New York is open, you need to translate both your local
time and the shop local time to GMT on the day you are making the query
and not on some arbitrary date, such as when the opening time was
entered into the database or 2020-01-01. In such an example, you really
do not want to convert to GMT on data input - you wait until the query
is performed.
I can find examples of TIME WITH TIME ZONE when the date for a
conversion to GMT is specified at data input (e.g. when inputting the
time code on a log file - as a shortform timestamp), but not for
conversion on some fixed date.
I would be happy to drop TIME WITH TIME ZONE. On the other hand, my
example would benefit from a built-in function to convert a local time
(in the database) and its time zone to GMT on a specific date (e.g. today).
Rather than encode time zone names in the database - when the time zone
is given as a separate column, I would specify a Domain for the Firebird
Time Zone ID in the RDB$TIME_ZONES file and use that for the column value.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
