14.06.2019 14:58, Mark Rotteveel wrote:
On 2019-06-13 22:12, Vlad Khorsun wrote:
13.06.2019 17:02, Adriano dos Santos Fernandes wrote:
On 13/06/2019 06:43, Vlad Khorsun wrote:
I don't offer to change internal representation (UTC +
offset\region_id) as is.
This is the only way to have correct comparison of timestamp with time
zone.
But i offer to change *external* representation to region_time +
offset\region_id
Even a different external representation would need to work as input
data when sending data from client to server.
Yes.
So as I said, a data that have dummy fields when using from
client->server I'm totally against.
You mix my two different offers:
a) use region time (not UTC) in external representation, and
b) add precalculates offset to the external representation
currenlty we speak about (a), which not add additional fields.
A extendable server->client data that has extra properties and could
also be used for the string problems I mentioned, I'm totally in favor.
So one (client) could request "give-me that timestamp-tz (utc timestamp
+ region/offset) columns
I still not understand for what purposes client could ask UTC timestamp
instead of region ? At last, he could convert it into UTC explicitly at
SQL level.
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.
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.
Regards,
Vlad
PS what do you think about offer (a) above ?
PPS Windows uses different region names than ICU, so WinAPI can't help to
convert
time from UTC to region, and it is interesting to know how to .Net drivers could
do it without some help from ICU (or similar software)...
https://stackoverflow.com/questions/17348807/how-to-translate-between-windows-and-iana-time-zones
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
