The libicu package shows tzdata at 2022e (icuinfo), but the installed tzdata is at 2023c. Is there some way to get the icu library to update to the latest tzdata?
Does the system have the correct time zone and display the time correctly?
The version of the tzdata package is not necessarily directly related to the info shown by libicu. In fact, most of the underlying data does not change.
I see the same
<param name="tz.version">2022e</param>
tzdata.noarch 2023c-1.fc38 @anaconda
Jeff, my own local time is fine - I know there have not been changes in a while, but that is not what I am worried about. I am writing a server app that uses ICU to manipulate and display date/time. I want to make sure it is up-to-date so that there is less chance that users in other locales see the wrong time.
I understand your concern and I do not do server apps.
However, the displayed TZ data is not necessarily out of sync, merely versions displayed differently. In fact, if your app is to be fully up to date it must pull from the most recently updated data source, which AFAIK is that used by the tzdata and tzdata-java packages. Realistically and for consistency it should be based on UCT and then possibly do displays in local time.
I do not know if icu uses the same data sources or not, but just recently there was a date change in when DST started within the EST time zone (Cairo, Egypt) and a thread here about that. The user had not done a recent update and when he did so his tzdata package was updated and the problem was fixed.
The info in the app also shows ICU using the older tzdata as well. Are you saying it’s using the up-to-date data even though the info shows it using an older version?
The dates are stored in UTC but converted to the user’s timezone for display using ICU.
I was wondering more as to why it doesn’t look for an use the installed tzdata package… or is that not compatible?
I just found this, looks like I can update the tzdata: TimeZone Classes | ICU Documentation
They have a separate repository that they keep up-to-date whenever the timezone database is updated, but looks like it must be updated separately.
That seems to mean it is using the proper data.
Sometimes an app uses and displays older data from within a package. The package version does not necessarily reflect the version of all the pieces it includes since it may actually use older and stable parts. Updating just one piece means the overall version number must be updated even though as much as 99.9% of the package was not changed. In the case of the time zone data only the data changed, not the supporting software.
A perfect example of this is the kernel itself. The kernel-headers package used with kernel 6.2.14 is version 6.2.6. This sometimes trips up users who expect (demand?) consistency in version numbers.
From what I’ve read and understand now, I don’t think that’s the case.
It looks like libicu comes with it’s own compiled version of tzdata, but it’s only updated when a new version of libicu is released - which can take a while.
But they do keep a repository of data files that get updated whenever new data in released, so I can just checkout that data and point libicu to those files and it should read in the new info. I am going to try it now.
Updating just one piece means the overall version number must be updated even though as much as 99.9% of the package was not changed.
True, but I have seen a number of people complain about time not being correct in certain parts of the world - it is almost always due to not having the latest tzdata being used.
It worked, I was able to get the tzdata reported by libicu to the latest by checking out the tzdata files compiled by ICU and pointing to them with the environment variable.
Glad you were able to resolve it. Using the variable seems more flexible and consistent as long as the software providing that variable for the data (and the data itself) does not fall out of sync.
Exactly what I described. An update fixed almost all those, and they were caused by failure to keep the system up to date. The errors will occur in all cases where time zone info has changed but the system has not been updated so is out of sync with the most recent data changes.
Since they provide the compiled data via a git repository it will be trivial to check it out and have a cron run daily to check for updates and checkout the changes.