11.06.2019 1:41, Vlad Khorsun wrote:
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.
This is the wrong statement that makes me to think in wrong direction.
The conversion between region ID and name is not at ICU level. It is in
Firebird code, see TIME_ZONE_LIST at src\common\TimeZones.h
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.
Yes. The real problem is to calculate offset from UTC time to local (region)
time.
Probably, it could be done using WinAPI, if:
- TimeZoneDesc::asciiName is the same as in Windows timezone database
- Windows have all necessary info for a region *and* for a given moment of time
The weak side of this (use Win API) is that we can't guarantee correct
conversion.
It's an optional dependency in the sense that only when these new IUtil
function are called ICU is needed.
It is mandatory in the sence that app needs a way to display data to the user.
I hardly see how ot can be done with no knowledge of value of offset from UTC...
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.
So, actially, we need not an "id to name" conversion table. We need whole time
zone database. It is a "bit" more complex task.
Another idea is to extend ISC_TIMESTAMP_TZ and always put displacement value
in it (with region code ID, if known).
What about this way ? I speak about client side only, i.e. not about storage.
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
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
