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