Dne 08. 07. 20 v 15:32 Mark Rotteveel napsal(a):
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).
It is not clear to me what problem you are having here.
The problem is how this is handled in Python standard library. It does
define only abstract base class for timezone handling
(https://docs.python.org/3.8/library/datetime.html#tzinfo-objects).
There are two implementations: packages dateutil and pytz. The pytz does
not support tzinfo for time objects at all, only for datetime
(timestamp). dateutil supports time with tzinfo, but it's practical
usability is limited to simple timezones with no timeshifts etc. I can't
even handle some of them in driver as it's not possible to get timezone
info like name or utcoffset without date part for these complex ones.
Then use 2020-01-01 as the date, because that is the date that
> Firebird itself uses for basing TIME WITH TIME ZONE derivation for
> named zones.
This was the first thing I did but then rejected the idea. It allows me
to store the TIME WITH TIMEZONE for such cases at the price that the
value is crewed for DST. I'd rather reject the value than store wrong one.
TIMESTAMP WITH TIMEZONE is ok.
B. Storing into database.
If a certain zone doesn't exist, you need to provide a mapping to the
appropriate zones you want to use. For example, CET *is* CEST. That
is: CET has a summertime rule, so the name CET is equivalent to CEST
on dates in summer time (CEST is just a dumb alias for CET during
summertime).
However, it is highly recommend to stop using those short form zone
identifiers as they are ambiguous. It is better to use the long form
identifiers like Europe/Prague.
And where I should get such mapping? Create and maintain it myself as
part of Firebird driver? This stuff is handled by dateutil Python
library that gets the data from system (on POSIX from description files,
on Windows from registry or API). For example on Linux (POSIX), the
'Europe/Prague' timezone actually maps to file
/usr/share/zoneinfo/Europe/Prague that contains data about this timezone
that dateutil parses and uses. In fact the 'Europe/Prague' name is not
part of this data so dateutil don't know it and can't return it, and
such timezone name is just used to find the file on filesystem when
tzinfo object is created. I also can't force dateutil to return CET
instead CEST as timezone name if the time falls to summer time. And
dateutil follows specification in POSIX zoneinfo file to get the name.
https://dateutil.readthedocs.io/en/stable/tz.html
All this stuff is based on standard system data definitions and routines
in standard libraries. I don't make up Python datetime objects with
timezone from thin air nor I fabricate them myself. If any Python
programmer will use standard way to get datetime with zoneinfo from
local system and pass it to the driver for storage in database, I must
handle it as is. I can't do any translations (especially not just for
some cases) in the driver. Mind that 12:30 in CET and CEST are different
times in UTC, and 12:30 in 'Europe/Prague' could be also different UTC
depending on the date. In current state of affairs it means that for
Python app. developer some timezones could be stored in the database and
some doesn't. It has to be user's responsibility to provide ones that
could be stored.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
