On 14-6-2019 17:33, Dimitry Sibiryakov wrote:
14.06.2019 17:09, Mark Rotteveel wrote:
And that is not really workable if the client does want to use offset
based values and for example doesn't know the zone Firebird uses, or
if Firebird uses an offset that is too large.
It doesn't matter. In Vlad's suggestion server always sends to client
both tz id and offset. If client want UTC, it can simply add offset to
received value and don't care about the rest.
And I repeat what I said earlier: if Firebird uses an offset that is too
large then I can't use the standard features in Java for date/time
handling and I'll need to mangle things myself to get a - hopefully -
meaningful value.
For me the current solution works and I'm going to be pretty pissed off
if things change this late.
The current problem has mainly to do with the string formatting that
fbclient can do for you, and I think the primary consumer of that
functionality is ISQL. I'd be surprised if other applications use that
regularly.
As I see it, the following solutions that will work fine:
1. If value is region-based and ICU is absent, render time as UTC
2. Firebird never returns region-based values and always converts them
to offset based values (as in UTC+offset)
3. Same as option 2, but control it through a DPB item and session
property, if ICU is absent, ISQL (and not fbclient(!)) will use this DPB
item on connect
4. If ICU is absent, ISQL (and not fbclient(!)) sets
isc_dpb_time_zone_bind=legacy and falls back to without time zone values
5. The 'pre-calculate offset on server' solution communicated in what
are currently padding bytes. Server communicates
UTC+region+calculated-offset (or UTC+offset+offset for consistency), the
second 'offset' is for presentation purposes only and when receiving
values the server will ignore them.
Option 1 is probably the simplest solution and a form of graceful
degradation. Option 2 or 3 would be a good solution as well (where
option 3 offers more flexibility as it will only be done for
applications that really need or want this, while allowing applications
that want to know the region to do so). Option 1 and 3 could be
combined, so even for situations where a region is returned (conversion
to offset not enabled), fbclient can still offer graceful degradation.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
