06.03.2019 17:26, Adriano dos Santos Fernandes wrote:
On 04/03/2019 11:08, Adriano dos Santos Fernandes wrote:
On 04/03/2019 10:57, Alex Peshkoff via Firebird-devel wrote:
On 3/4/19 3:15 PM, Vlad Khorsun wrote:
04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
On 3/4/19 2:57 PM, Vlad Khorsun wrote:
I have additional question: is it true that fbclient now depends
on ICU ?
As fas as I know - not. At least IntlManager.cpp is placed in
src/jrd, which is used only in engine.
Client is using other (OS-specific) tools for charsets conversions.
Look at UtilInterface::decodeTimeTz() - it calls
TimeZoneUtil::decodeTime()
TimeZoneUtil::decodeTimeStamp()
Jrd::UnicodeUtil::getConversionICU()
Yes. Now I see - any ICU version was always loadable by some functions
in common library but that functions were never called in fbclient. Now
with TZ support it does...
But I'm unsure how this can be fixed. Should we force all TZ support to
be moved to server? May be taht makes sense - in a case when we start to
work with TZ-related data we should already have connection with any
engine.
I suppose that any "real" dependency here is to transform TZ-id to
string and vice-versa.
Let me correct myself. It's not to convert IDs to/from strings, but to
convert UTC time to region time as string form, as in descriptors the
data is stored in UTC.
It's an optional dependency in the sense that only when these new IUtil
function are called ICU is needed.
How client app should work with ISC_TIMESTAMP_TZ data type to avoid this
optional dependency ? Is it possible to ask for displacement value instead
of region code ID ?
I do not think an utility function that converts time from regions
should require a server call.
In ideal world - yes, i agree. But in real world there could be:
- client have no ICU libraries at all, or
- client have some ICU library, but it can't convert region ID obtained from
server (because of different ICU version), or even
- wrong conversion of region ID at client side because of mismatched ICU
version (sounds impossible, but not improbable)
One of "simple" solutions could be to ask sever once for whole conversion
table and to keep it at some temp file (or nearby fbclient\app) for future
usage.
It is also not ideal, as different servers could have different ICU versions,
but
it could be a starting point to think on the better solution.
Another idea is to extend ISC_TIMESTAMP_TZ and always put displacement value
in it (with region code ID, if known). In the case of the absence of ICU at
client side app could show this displacement value instead of region name.
I can imagine apps that prefer to always show displacement value, btw. I.e.
"2019-06-11 01:18:39.0630 Europe/Kiev" is not always better than just
"2019-06-11 01:18:39.0630 +03:00"
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
