On 14-6-2019 14:56, Vlad Khorsun wrote:
14.06.2019 14:58, Mark Rotteveel wrote:
I prefer the current approach where the time is communicated in UTC
with the offset or region information added for presentation purposes.
Having the time in UTC will always allow a fallback to at least a
usable value instead of having a meaningless value if the region is
unknown or - for example - the offset is invalid (eg the maximum range
of offsets supported by Firebird is wider than the range of offsets
supported by Java).
Mapping between region_ID and regin_Name could be easily obtained
from server
(RDB$TIME_ZONES) if necessary. It could be done once per client process
lifetime.
Initial mapping could be hardcoded into Jaybird and updated when necessary.
We can even auto generate corresponding file from ICU sources as it
currently
done for fbclient.
There is no guarantee that Java has a suitable time zone mapping for the
names used by Firebird. So in that case I would have a meaningless
value. I repeat, having the value in UTC clientside provides options for
meaningful fallback.
While implementing this feature in Jaybird I even considered using the
approach used by the PostgreSQL JDBC and that was simply always using
the UTC time and not even bothering with the offset and region information.
I think you are considering this a bit too much from the perspective
of flexible ad-hoc querying, instead of general usage of SQL in an
application that might be deployed to widely varying environments
where you won't have the luxury of changing the query or the session
time zone to fix a problem.
I consider a nightmare of deploying and maintaining ICU libraries at
every
client machine.
Then another solution needs to be found. Maybe Firebird should always
communicate offsets instead of regions, or the pre-calculated offset
mentioned elsewhere could be solution.
Regards,
Vlad
PS what do you think about offer (a) above ?
We were discussing (a) (value is in target zone) here and I don't like
it. If anything, maybe (b) (pre-calculate offset) might work, but that
could be ambiguous (eg consider what happens with a value that has an
offset and a pre-calculated offset with different values).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
