06.03.2019 18:26, Adriano dos Santos Fernandes пишет:
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 is so. The IBExpert developer couldn’t correctly handle time zone
types, which I advised him to use IUtil.decodeTimeTz. In fact, for such
an application it is not scary, since what fbclient loading is indicated
in the application itself. But if fbclient is installed globally, then
dependency on the ICU can cause many problems.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
