On 14/06/2019 09:56, Vlad Khorsun wrote: > > Mapping between region_ID and regin_Name could be easily obtained > from server > (RDB$TIME_ZONES) if necessary. It could be done once per client > process lifetime. > Initial mapping could be hardcoded into Jaybird and updated when > necessary. > We can even auto generate corresponding file from ICU sources as it > currently > done for fbclient. > No one uses the same names, so one (ICU) was chosen.
Note that ICU is a theoretical implementation detail, so Firebird has a gateway for it also in the client to not reimplement it. But this is important: at least currently, ICU is an implementation detail. Currently if Firebird wants to implement some time zone not present in ICU, it can. Not saying it should. So as everyone has they own names, Firebird has it too. And it also has the IDs. So IDs and names are fixed in Firebird and to use ICU Firebird maps these names to ICU names (a actual 1-1 as currently the same names are used). > > I consider a nightmare of deploying and maintaining ICU libraries at > every > client machine. > > I present you the choice of build it statically. Timezone tables could be external and update procedure is documented in our readme. Maybe the problem is that it's not easy to build it statically as seems nobody ever did it because nobody thought it would be useful and didn't considered any nightmare. > > > PPS Windows uses different region names than ICU, so WinAPI can't help > to convert > time from UTC to region, and it is interesting to know how to .Net > drivers could > do it without some help from ICU (or similar software)... > As said someone always will cry but we can't have different set of timezone names per platform, so people could: 1) Use ICU compatible functions 2) Map FB names to they platform/library - the same thing happens with character sets Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
