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.
and additionally give-me its string
representation or offset or whatever".
At same time I'm totally against on removing the functions already
present in the client that makes ICU a optional dependency only when
they are called.
Your functions actually *translate and* encode\decode. If external
representation already translated into region tz new functions become
not needed. All we could ask additionally is to translate region ID
into region name (as descussed and agreed in prior message).
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
