Tzdb: Apr-April Issue: Request to provide ETA for next release with the fix - 2024c
Greetings Team, I am writing to bring to your attention a critical issue we've encountered with the recent release of https://github.com/eggert/tz -version 2024b. We are using https://github.com/HowardHinnant/date library for our scheduler, the changes with 2024b have caused our schedulers to fail across thousands of agents. Given the scale of our deployment, manually fixing each affected agent is not a feasible solution for us. I see the issue has been fixed in the repo, I really appreciate making a quick fix. Could you please provide an estimated timeline for when we can expect a new release with the fix. If possible, we would greatly appreciate it if you could expedite the release with the fix. Thank you very much for your prompt attention to this matter. We look forward to your response. Thanks Srinivas.
On 2024-09-09 10:35, sattisrinivas89--- via tz wrote:
I am writing to bring to your attention a critical issue we've encountered with the recent release of https://github.com/eggert/tz -version 2024b. We are using https://github.com/HowardHinnant/date library for our scheduler, the changes with 2024b have caused our schedulers to fail across thousands of agents. Given the scale of our deployment, manually fixing each affected agent is not a feasible solution for us.
I see the issue has been fixed in the repo, I really appreciate making a quick fix.
Could you please provide an estimated timeline for when we can expect a new release with the fix. If possible, we would greatly appreciate it if you could expedite the release with the fix.
Thank you very much for your prompt attention to this matter. We look forward to your response.
Please read the posts in the thread with subject "2024b", and note that all parsers should comply with the zic(1) documentation, allowing all entries to be any case, and any unambigous length up to full unabbreviated names. As your issue is with the downstream consumer of tzdata source, who originally raised the data issue, they should be upgrading their parser to handle the full range of un-/abbreviated names as per the referenced zic(1) documentation. In practical terms, downstream consumers can use make to produce vanguard.zi, then change your parsers to accept all those abbreviations and values; also write a sed or similar script to expand all names in the concatenated data files to full unabbreviated length, and change your parsers to accept those also. From previous data issues, you may use the committed changes to the data in the experimental Github repo if you need updated files before the next release, as releases are only made when there are substantive impending changes in the next weeks (or days unfortunately!) Remember not all software supply chain issues are hacks: most are bugs, and your designs and deployments have to take into account any possible issues with upstream software and data, and how you can deal with anything that happens, as yours is the legal liability, not the person or project from which you are taking the software and data, who could walk away from it as soon as they are finished, or take it offline if they get annoyed by too many complaints! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
participants (2)
-
brian.inglis@systematicsw.ab.ca
-
sattisrinivas89@gmail.com