Re: [Firebird-devel] IBlob::getSegment() and the last segment
29.04.2020 19:11, Alex Peshkoff via Firebird-devel wrote: On my mind they both assume a) Yes. You are right. Sorry. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Installing the ICU Files under Windows
On 2020-04-28 16:55, Tony Whyman wrote: 2. There is a risk of a stealth (ICU) upgrade under Linux if the upgrade affects indexes that depend upon character set collation sequences. FYI - gfix is ready to help with this, it's enough to use switch: -icu fix database to be usable with present ICU version Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IBlob::getSegment() and the last segment
On 2020-04-29 20:11, Alex Peshkoff via Firebird-devel wrote: On 2020-04-29 18:09, Dmitry Sibiryakov wrote: Hello, All. What should be the behavior of getSegment() reading the last segment of the BLOB? a) Return some data of non-zero length and return RESULT_OK, next call shall return zero length data and RESULT_NO_DATA; b) Return some data of non-zero length and return RESULT_NO_DATA. a) In examples folder there are two examples of BLOB reading and one assume behavior a) while second expects b). Which is wrong? On my mind they both assume a) And therefore work correctly. PS. I was thinking about adding return value RESULT_LAST_DATA in order to save one call to blob and following b) logic regarding data, but that's for the future. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IBlob::getSegment() and the last segment
On 2020-04-29 18:09, Dmitry Sibiryakov wrote: Hello, All. What should be the behavior of getSegment() reading the last segment of the BLOB? a) Return some data of non-zero length and return RESULT_OK, next call shall return zero length data and RESULT_NO_DATA; b) Return some data of non-zero length and return RESULT_NO_DATA. a) In examples folder there are two examples of BLOB reading and one assume behavior a) while second expects b). Which is wrong? On my mind they both assume a) And therefore work correctly. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: New API and scrollable cursors
On 2020-04-29 19:34, Dmitry Yemanov wrote: 29.04.2020 18:50, Dmitry Yemanov wrote: Client side cursor appears not too complex at the first glance, but not sure do we want to have client or server side cursor. Scrollable cursor is already materialized at the server side, so I see no point doubling efforts on the client. It should remain being server-side. Well, of course the remote provider can clear the SCROLLABLE flag when passing the statement to the server side. In this case the cursor will be uni-directional in the engine and the remote provider may implement its own buffer for scrollability. But I'm still not sure this is a good way to go. Utilizing the already existing engine-level scrollability seems being a better option to me. Looks like we think in same direction... Ideally we should have both cases. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: New API and scrollable cursors
On 2020-04-29 18:50, Dmitry Yemanov wrote: 29.04.2020 17:50, Alex Peshkoff wrote: Client side cursor appears not too complex at the first glance, but not sure do we want to have client or server side cursor. Scrollable cursor is already materialized at the server side, so I see no point doubling efforts on the client. It should remain being server-side. As far as I remember MSSQL supports both types (at least that how it was 15-20 years ago). When implementing client-side scrollable cursor client can turn off scrollable flag for server and materialize cursor itself. I do not insist on such solution but IMHO it can be useful at least in some cases. It can reduce both network traffic and server load. As a dark side use of WHERE CURRENT OF for such cursor will require additional efforts. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: New API and scrollable cursors
29.04.2020 18:50, Dmitry Yemanov wrote: Client side cursor appears not too complex at the first glance, but not sure do we want to have client or server side cursor. Scrollable cursor is already materialized at the server side, so I see no point doubling efforts on the client. It should remain being server-side. Well, of course the remote provider can clear the SCROLLABLE flag when passing the statement to the server side. In this case the cursor will be uni-directional in the engine and the remote provider may implement its own buffer for scrollability. But I'm still not sure this is a good way to go. Utilizing the already existing engine-level scrollability seems being a better option to me. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: New API and scrollable cursors
29.04.2020 17:50, Alex Peshkoff wrote: Client side cursor appears not too complex at the first glance, but not sure do we want to have client or server side cursor. Scrollable cursor is already materialized at the server side, so I see no point doubling efforts on the client. It should remain being server-side. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] IBlob::getSegment() and the last segment
Hello, All. What should be the behavior of getSegment() reading the last segment of the BLOB? a) Return some data of non-zero length and return RESULT_OK, next call shall return zero length data and RESULT_NO_DATA; b) Return some data of non-zero length and return RESULT_NO_DATA. In examples folder there are two examples of BLOB reading and one assume behavior a) while second expects b). Which is wrong? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: New API and scrollable cursors
On 2020-04-29 08:19, Dmitry Yemanov wrote: 29.04.2020 00:36, Karol Bieniaszewski пишет: May i ask if this is big developmenet cost to support it on the client side api? It's supported in the API, but not supported in the remote protocol. IIRC, it can be easily implemented if a scrollable cursor would disable client-side asynchronous prefetch. But I didn't like that idea in the past. Other implementations are not that trivial. Client side cursor appears not too complex at the first glance, but not sure do we want to have client or server side cursor. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 11:00, Tony Whyman wrote: > On 29/04/2020 13:59, Adriano dos Santos Fernandes wrote: >>> There probably should thus be a firebird-tzdata package as part of the >>> set of (deb/rpm) Firebird packages containing the latest tzdata files. >>> It should then be easy enough for the package maintainer to roll out >>> updates to the time zone database through the usual channels. >> That would be good. >> > Some one also needs to fix the daily snapshot Linux build for FB4 to > include the tzdata directory. Noted. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 13:59, Adriano dos Santos Fernandes wrote: There probably should thus be a firebird-tzdata package as part of the set of (deb/rpm) Firebird packages containing the latest tzdata files. It should then be easy enough for the package maintainer to roll out updates to the time zone database through the usual channels. That would be good. Some one also needs to fix the daily snapshot Linux build for FB4 to include the tzdata directory. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On Wed, 29 Apr 2020 13:16:11 +0100 Tony Whyman wrote: > I don't claim any expertise on linux time zone files. However, there is a > ubuntu package "tzdata" which claims to include all the timezone files. I > am currently using Linux Mint 19.3 (ubuntu 18.04) and the most recent > changelog entry for my version of the tzdata package is: > > tzdata (2019c-0ubuntu0.18.04) bionic; urgency=medium > FWIW, in SuSE the rpm is called 'timezone' and that too is up-to-date, at least in my version of 15.1. That is to say it has the 2019c updates. 2020a release only appeared this week, so it will probably arrive in a few days. IMO, we can probably assume linux distros that are being maintained will have the correct timezone files. And of course no-one would deploy to a linux server that wasn't running an actively maintained distribution. Can anyone confirm the situation with Windows? I find it hard to believe that Microsoft aren't on the ball with this. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 09:49, Tony Whyman wrote: > > > There probably should thus be a firebird-tzdata package as part of the > set of (deb/rpm) Firebird packages containing the latest tzdata files. > It should then be easy enough for the package maintainer to roll out > updates to the time zone database through the usual channels. That would be good. > However, Windows is still a problem. > Not really, it's easy. But a simple solution like a power shell script that downloads and update the files could be even easier. I'd like to add it if someone contributes. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 13:27, Adriano dos Santos Fernandes wrote: On 29/04/2020 08:37, Paul Reeves wrote: On Wed, 29 Apr 2020 11:59:43 +0100 Tony Whyman wrote: Hopefully, an installer package will eventually be made available to automate the process. However, the above manual procedure is all that is currently available. I'm wondering how people think we could automate this process. Thoughts that immediately come to mind are: - We have no control over the release cycle of tzdata. The update to https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata seems to be manual at the moment. Looks like you are not aware of things, where automated daily github action peeks changes in https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew and creates a pull request for us. It has just happened this week. Adriano My own view is that a Windows Installer Package for tzdata is essential if the time zone database is to be kept up-to-date. Recall that most operational deployments are highly controlled production environments where the System Administrator will demand that updates are strictly controlled and subject to source verification. It also should be possible to quickly roll back any updates if a problem is found. If the pull request is automated then it should not be difficult to rebuild the tzdata installation package automatically and, once it has been tested, it can be formally released with an EMail announcement sent out to alert interested parties. 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
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 13:22, Adriano dos Santos Fernandes wrote: This has nothing to do with ICU. There is no ICU tz data package in Ubuntu. The data is with the libicu package inside the libraries. OK. That seems to be supported by the ICU documentation. There probably should thus be a firebird-tzdata package as part of the set of (deb/rpm) Firebird packages containing the latest tzdata files. It should then be easy enough for the package maintainer to roll out updates to the time zone database through the usual channels. However, Windows is still a problem. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 13:16, Tony Whyman wrote: The most recent Debian version is 2020a-1 (released 4 days ago). so I'll be interested to see how quickly that feeds down to ubuntu 18.04 - if ever. Its changelog is 2020a is the first release of TZ for 2020 and in addition to the Morocco and Yukon offset changes it also includes a change to timezone identifiers so America/Godthab has been renamed to America/Nuuk There were only 3 releases in 2019 which is a little strange, with 2019c being released last December, but the changes spread over the period and their actual corrections can be found in the development repository https://github.com/eggert/tz -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 08:37, Paul Reeves wrote: > On Wed, 29 Apr 2020 11:59:43 +0100 > Tony Whyman wrote: > >> Hopefully, an installer package will eventually be made available to >> automate the process. However, the above manual procedure is all that is >> currently available. > I'm wondering how people think we could automate this process. Thoughts that > immediately come to mind are: > > - We have no control over the release cycle of tzdata. The update to > https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata > seems to be manual at the moment. > Looks like you are not aware of things, where automated daily github action peeks changes in https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew and creates a pull request for us. It has just happened this week. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 09:16, Tony Whyman wrote: > On 29/04/2020 12:12, Adriano dos Santos Fernandes wrote: >> In Linux (Ubuntu as least) and probably MacOS, the ICU time zone >> database is not maintained updated in an Ubuntu release. I guess even if >> they rebuild and update the library, it still comes with the original tz >> database. >> >> So the process of update tz data with *.res files should be for all >> platforms. > > I don't claim any expertise on linux time zone files. However, there > is a ubuntu package "tzdata" which claims to include all the timezone > files. I am currently using Linux Mint 19.3 (ubuntu 18.04) and the > most recent changelog entry for my version of the tzdata package is: > > This has nothing to do with ICU. There is no ICU tz data package in Ubuntu. The data is with the libicu package inside the libraries. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 12:37, Paul Reeves wrote: - The changes will, in all probability, more than 99% of the time, have no relevance for over 99% of our users. But can one take the risk of ignoring them? Unfortunately this 'excuse' is quite prevalent in most actions relating to TZ ... How do I ensure that data I distribute which includes World War Two time offsets will be handled correctly if the user does not have 'backzone' on their setup. It's too difficult so handle pre-1970 data so we will ignore it! The vast majority of users will never know ... - Even if we can provide timely, automated updates how will a server installation know to look for them? A task scheduler of some sort would need to check. We don't have one built in to Firebird so it would mean adding something platform specific. This part of my objection to even having wasted the time to include a restricted support for timezones AT ALL in FB4. The starting point of solving the problem of handling potentially critical changes to TZ data is tzdist, but while the RFC has been approved, no one has stepped up to the plate to provide a feed. The whole point of tzdist is that you can ask if a rule set has changed since it was last used ( or even since the data was normalized ) and one can at least establish if the event you published for say next week will be at the same UTC time if astronomical observations have change the start of Ramadan for example. tzdist also provides validation of the time frame over which a rule set is valid so one can flag when there is no offset available for a pre1970 date. This is not a firebird problem ... this is a problem with the core data, and TZ is only required to provide post 1970 data. There is no source of pre 1970 data that can be relied on despite the fact that a growing historic record is being validated even in the TZ backzone data. SO TODAY ... the best way of working is using UTC normalized data along with additional fields recording location and version and type of tz data used to provide that normalization! The FB4 'timezone' is yet another unreliable data source! And this is the same for historic data and published calendars for the coming 6 months ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 12:12, Adriano dos Santos Fernandes wrote: In Linux (Ubuntu as least) and probably MacOS, the ICU time zone database is not maintained updated in an Ubuntu release. I guess even if they rebuild and update the library, it still comes with the original tz database. So the process of update tz data with *.res files should be for all platforms. I don't claim any expertise on linux time zone files. However, there is a ubuntu package "tzdata" which claims to include all the timezone files. I am currently using Linux Mint 19.3 (ubuntu 18.04) and the most recent changelog entry for my version of the tzdata package is: tzdata (2019c-0ubuntu0.18.04) bionic; urgency=medium * New upstream version, affecting the following future timestamps: - Fiji's next DST transitions will be 2019-11-10 and 2020-01-12 instead of 2019-11-03 and 2020-01-19. - Norfolk Island will observe Australian-style DST starting in spring 2019. The first transition is on 2019-10-06. -- Adam Conrad Fri, 20 Sep 2019 03:11:15 -0600 which seems pretty recent to me. This is also the current version for 16.04 and 19.04. Checking the ubuntu package webpage, it looks like 2019c-3 has been rolled out to 19.10. Although the changelog suggest nothing important in the minor patch. The most recent Debian version is 2020a-1 (released 4 days ago). so I'll be interested to see how quickly that feeds down to ubuntu 18.04 - if ever. Its changelog is tzdata (2020a-1) unstable; urgency=medium * New upstream version, affecting the following future timestamps: - Morocco springs forward on 2020-05-31, not 2020-05-24. - Canada's Yukon advanced to -07 year-round on 2020-03-08. * Bump Standards-Version to 4.5.0 (no changes). -- Aurelien Jarno Fri, 24 Apr 2020 21:32:19 +0200 I would certainly prefer to rely on the Ubuntu update cycle for the tzdata rather than a manual update and the above suggests that this should be possible. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
You can posrt the difference between new ICU versoins in firebirdsql.org to help developers/users/admins to decide wheter an update nedded at all. -Eredeti üzenet- Feladó: Paul Reeves [mailto:pree...@mail.ibphoenix.com] Küldve: 2020. április 29., szerda 13:38 Címzett: firebird-devel@lists.sourceforge.net Tárgy: Re: [Firebird-devel] ICU File Deployment Guidance On Wed, 29 Apr 2020 11:59:43 +0100 Tony Whyman wrote: > Hopefully, an installer package will eventually be made available to > automate the process. However, the above manual procedure is all that is > currently available. I'm wondering how people think we could automate this process. Thoughts that immediately come to mind are: - We have no control over the release cycle of tzdata. The update to https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata seems to be manual at the moment. - Looking at the update history over at https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew there can be up to 10 changes per year. - The changes will, in all probability, more than 99% of the time, have no relevance for over 99% of our users. But can one take the risk of ignoring them? - Even if we can provide timely, automated updates how will a server installation know to look for them? A task scheduler of some sort would need to check. We don't have one built in to Firebird so it would mean adding something platform specific. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel __ Information from ESET Mail Security, version of virus signature database 21244 (20200429) __ The message was checked by ESET Mail Security. http://www.eset.com __ Information from ESET Mail Security, version of virus signature database 21244 (20200429) __ The message was checked by ESET Mail Security. http://www.eset.com Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On Wed, 29 Apr 2020 11:59:43 +0100 Tony Whyman wrote: > Hopefully, an installer package will eventually be made available to > automate the process. However, the above manual procedure is all that is > currently available. I'm wondering how people think we could automate this process. Thoughts that immediately come to mind are: - We have no control over the release cycle of tzdata. The update to https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata seems to be manual at the moment. - Looking at the update history over at https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew there can be up to 10 changes per year. - The changes will, in all probability, more than 99% of the time, have no relevance for over 99% of our users. But can one take the risk of ignoring them? - Even if we can provide timely, automated updates how will a server installation know to look for them? A task scheduler of some sort would need to check. We don't have one built in to Firebird so it would mean adding something platform specific. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On 29/04/2020 07:59, Tony Whyman wrote: > > Many thanks to those who responded yesterday to my question on ICU > library file installation under Windows. I am in the process of > updating the IBX User Manual to include the Firebird 4 extensions and > this question arose when updating the deployment guidelines. > Specifically, giving IBX users guidance on when to include and provide > an update mechanism for the time zone database. > > it is important to get this guidance right as the target reader is a > developer using IBX and Firebird but who does not intend to become an > expert in Firebird installation. Standalone clients and embedded > server installations are the main focus. > > The draft text for the IBX deployment guidelines for the ICU files > follows. I would be grateful for any review comments that can point to > any remaining mis-understandings I may have about how the time zone > database is used and deployed in Firebird 4. > > It's good in general, but you mix some things in relation to ICU Library x ICU TZ Database. In Linux (Ubuntu as least) and probably MacOS, the ICU time zone database is not maintained updated in an Ubuntu release. I guess even if they rebuild and update the library, it still comes with the original tz database. So the process of update tz data with *.res files should be for all platforms. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ICU File Deployment Guidance
Many thanks to those who responded yesterday to my question on ICU library file installation under Windows. I am in the process of updating the IBX User Manual to include the Firebird 4 extensions and this question arose when updating the deployment guidelines. Specifically, giving IBX users guidance on when to include and provide an update mechanism for the time zone database. it is important to get this guidance right as the target reader is a developer using IBX and Firebird but who does not intend to become an expert in Firebird installation. Standalone clients and embedded server installations are the main focus. The draft text for the IBX deployment guidelines for the ICU files follows. I would be grateful for any review comments that can point to any remaining mis-understandings I may have about how the time zone database is used and deployed in Firebird 4. == The ICU Files For character set management including collation sequences, Firebird uses an external code library - International Components for Unicode” (ICU). Firebird 4 and later also uses this code library as the source of its Time Zone Database. This is used in support of TIME/TIMESTAMP WITH TIME ZONE data types and to convert local times to and from GMT taking into account the time zone and any daylight savings time offsets that need to be applied. The ICU library is deployed as a DLL or Shared Object (.so) and may be provided as part of the Operating System. * For Linux distros, the ICU shared objects are always deployed by the distro and are kept up-to-date as part of the normal OS update cycle. * For Microsoft Windows, the ICU DLLs have been included in the Windows OS from Windows 10 Version 1703 (Creators Update) onwards. They are not present in earlier versions of Windows. However, Firebird will always ignore the Windows ICU files and will instead use the ICU files installed with the database and located in the Firebird installation folder. * For macOS, the ICU shared objects are provided as part of macOS. The ICU library needs to be up-to-date in order to correctly translate local times to and from GMT. This is because, from time to time, there are legislative changes to time zones and daylight savings times and these need to recorded in the ICU library. /Note that as the ICU libraries are also used for character set collation sequences, an updated ICU library can also include a change to character set collations and thus may require that any indexes that depend upon an updated collation sequence have to be rebuilt – or a gbak backup/restore cycle is used to rebuild the indexes./ Updating the Time Zone Database under Linux or macOS This is performed automatically when an OS update is performed and the update contains an updated ICU. Most Linux distros can usually be relied upon to role out updates to time zone databases in a timely manner. Updating the Time Zone Database under Windows Each Firebird incremental release includes the most up-to-date version of the time zone database when it is released. However, the time zone database may also need to be updated between Firebird releases. This is not performed automatically under Windows and has to be manually initiated. Under Windows and in order to avoid having to update the time zone database without also needing a full ICU library update, a copy of the time zone database files are held in the \tzdata folder, as a set of '*.res' files. These are used in preference to the time zone database in the ICU DLLs. The time zone database can be updated by simply replacing these files. When new versions of the time zone database files are released, they are made available at: https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata The file “le.zip” can be downloaded from this page and contains the replacement '*.res' files for use on little endian architectures (e.g. Intel and AMD64 architectures). These have to extracted and the current versions in the \tzdata folder replaced with the updated versions from the zip. Hopefully, an installer package will eventually be made available to automate the process. However, the above manual procedure is all that is currently available. The time zone database for both Firebird Server and embedded server installations should be kept up-to-date and the source of the time zone database files regularly checked for updates. Client Side Considerations For character set collations, only the Firebird server/embedded server needs access to the ICU library. However, by default, Firebird clients also require access to the ICU library (or tzdata files) for time zone information. In Firebird 4 Beta 1 client local access to the ICU library was mandatory. However, in later versions, this is optional and it is possible for a Firebird client to rely on the server for all time zone computations. This mode
