Recommendations to governments about time zone update notice period and format
The latest short-notice time zone change from Egypt, so soon after the Mexico changes, made me wonder... Would it be useful to have a canonical thread or set of links in the TZDB docs to point to for user-facing "Why hasn't my device updated?" or government-facing "Why didn't our legislation change reach citizen's devices in time?" -type questions? For example, here are recommendations/policy I know of for a couple of widely-used operating systems / platforms: Android: https://source.android.com/docs/core/connect/time/time-zone-policy-recommend... (this is relatively new) Windows: https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-managem... Maybe these could be collated and extended for other consumers of TZDB. ------- I vaguely remembered there being something in the TZDB docs that says something along these lines [*] but I couldn't find it and might be getting confused with threads on the mailing list. I don't honestly expect having it written down to make a lot of difference, but the regular lack of notice and confusion about what *exactly* governments have changed makes me think there *could* be a set of recommendations. Then, governments that *want* to do the right thing could then know what to provide / expect and plan accordingly, and ones that don't try can be easily informed why things didn't work out like they may have expected. Thanks, Neil. [*] e.g. maybe something like "Many downstream users of the TZDB wait for an official TZDB release before they will produce an update to time zone behavior in consumer devices and software products. After TZDB has been updated, various parties have to perform their own integration, testing, and rollout of an update before users will see changes. These updates can be expensive, e.g. for the QA process itself and the network costs for updates to each TZDB copy. Updates may be batched with other updates and take substantial time to reach users after the TZDB release. Updates will require that affected products have a suitable update mechanism in place and are still supported." -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
On 2023-03-06 04:41, Neil Fuller via tz wrote:
The latest short-notice time zone change from Egypt, so soon after the Mexico changes, made me wonder...
Would it be useful to have a canonical thread or set of links in the TZDB docs to point to for user-facing "Why hasn't my device updated?" or government-facing "Why didn't our legislation change reach citizen's devices in time?" -type questions?
For example, here are recommendations/policy I know of for a couple of widely-used operating systems / platforms:
Android: https://source.android.com/docs/core/connect/time/time-zone-policy-recommend... <https://source.android.com/docs/core/connect/time/time-zone-policy-recommend...> (this is relatively new)
Windows: https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-managem... <https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-managem...>
Maybe these could be collated and extended for other consumers of TZDB.
-------
I vaguely remembered there being something in the TZDB docs that says something along these lines [*] but I couldn't find it and might be getting confused with threads on the mailing list.
Refs in ml and tz-link.html [2016 blog post URL changed but still works] to: https://codeofmatt.com/on-the-timing-of-time-zone-changes/ under: https://codeofmatt.com/author/matt/ which was followed up in July 2016 with: https://codeofmatt.com/time-zone-chaos-inevitable-in-egypt/ while he was still working for MS IIRC.
I don't honestly expect having it written down to make a lot of difference, but the regular lack of notice and confusion about what /exactly/ governments have changed makes me think there /could/ be a set of recommendations. Then, governments that /want/ to do the right thing could then know what to provide / expect and plan accordingly, and ones that don't try can be easily informed why things didn't work out like they may have expected.
[*] e.g. maybe something like "Many downstream users of the TZDB wait for an official TZDB release before they will produce an update to time zone behavior in consumer devices and software products. After TZDB has been updated, various parties have to perform their own integration, testing, and rollout of an update before users will see changes. These updates can be expensive, e.g. for the QA process itself and the network costs for updates to each TZDB copy. Updates may be batched with other updates and take substantial time to reach users after the TZDB release. Updates will require that affected products have a suitable update mechanism in place and are still supported." As governments and/or official airlines also have to update IATA so scheduled flight times in the SSIM are correct, we should push for this mailing list to be copied on those official distribution lists, so we do not rely on locals submitting links to news articles which may lack information that government laws, decrees, or regulations /may/ include.
There have been suggestions for FAQs addressing various stakeholders: governments, contributors, libc/utility maintainers, package maintainers, distros, vendors, end users. Could we have a FAQ that at least linked to the relevant posts for each. Perhaps those responsible in vendors, and employees contributing to distros, could get together and colloborate off-list to create and post here suitable docs, at least containing links, or preferably (links to) articles, like the above, the how to, etc. that could be freely distributed, published, and referenced? Links to these targeted FAQs could then be quoted in replies to government officials, etc. -- 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
On 2023-03-06 03:41, Neil Fuller via tz wrote:
[*] e.g. maybe something like "Many downstream users of the TZDB wait ...
Thanks for the suggested wording. I folded it into a new section in tz-link.html, with the title "Coordinating with governments and distributors", by installing the attached proposed patch. Once it's released (which should be soon, for Egypt) we can cite this URL: https://data.iana.org/time-zones/tz-link.html#coordinating Further comments welcome of course. Brian suggested something more ambitious (and more laborious...). I sometimes wonder how the IATA's process works for updating the SSIM's time zone appendix. Since they charge $1000/year for the SSIM I've never used it directly.
On 2023-03-08 00:55, Paul Eggert via tz wrote:
On 2023-03-06 03:41, Neil Fuller via tz wrote:
[*] e.g. maybe something like "Many downstream users of the TZDB wait ...
Thanks for the suggested wording. I folded it into a new section in tz-link.html, with the title "Coordinating with governments and distributors", by installing the attached proposed patch. Once it's released (which should be soon, for Egypt) we can cite this URL:
https://data.iana.org/time-zones/tz-link.html#coordinating
Further comments welcome of course.
+Many downstream timezone data distributors wait for +a <code><abbr>tzdb</abbr></code> release before they produce an update Prefix "official" before "release" and suffix something like "announced on the official tz-announce mailing list, see: https://mm.icann.org/mailman/listinfo/tz-announce for details, to subscribe, or view the archives: https://mm.icann.org/pipermail/tz-announce/" Are no current or latest month archive links supported as on some lists?
Brian suggested something more ambitious (and more laborious...).
They have the greater needs, presuambly documented and scheduled processes, and the funding to coordinate more comprehensive and expansive documents, explaining their needs, processes, and time frames.
I sometimes wonder how the IATA's process works for updating the SSIM's time zone appendix. Since they charge $1000/year for the SSIM I've never used it directly.
Can't even read the procedure without paying the fee! For background see: https://www.brucoord.org/coordination-process "IATA schedules conferences Schedules Conferences are held twice each year (June and November) about five months before the start of the respective schedules seasons and are organised by IATA. ... Slot handback deadline ... Unwanted slots must be returned no later than January 15 for the next Northern Summer season and no later than August 15 for the next Northern Winter season." referencing: https://www.brucoord.org/_files/ugd/ce8296_17aebc30ea66447b9a994de7d3c687b5.... There are also notice periods like notification of cancellation three weeks prior to operation of a scheduled slot. Presumably on a short notice time change, the slots in UTC are bumped in local time, to avoid disrupting schedules, and it is presumably then up to commercial airlines to apply for exemptions and make provisions for Justified Non-Use of Slots (“JNUS”) if they lack demand, ATC, airline, or airport personnel to operate commercial scheduled flights at those slot times, or negotiate with other carriers/operators for slot exchanges. Of course there may be national, airport, or airline regulations that mandate operation for political reasons or to maintain slots (e.g. EU 80%). Those with experience of IATA schedules, airline/airport operation, or travel industry can correct any presumptions. -- 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
On 2023-03-08 2:55 AM, Paul Eggert via tz wrote:
-If your government plans to change its time zone boundaries or -daylight saving rules, inform <code>tz@iana.org</code> well in -advance, as this will coordinate updates to many cell phones, -computers, and other devices around the world. -The change should be officially announced at least a year before it affects -how clocks operate; otherwise, there is a good chance that some -clocks will operate incorrectly after the change, due -to delays in propagating updates to software and data. The shorter -the notice, the more likely clock problems will arise; see "<a -href="https://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/">On -the Timing of Time Zone Changes</a>" for examples. -The <code><abbr>tz</abbr></code> data can represent planned changes -far into the future, and a long-planned change can easily be reverted -or otherwise altered with a year's notice before the change would have -affected clocks. It seems to me something like this should be front and center on the main IANA Time Zone Database page: https://www.iana.org/time-zones
It seems you'd really like to get this message to the lawmakers and authorities who make these decisions. They aren't as likely to learn this if the message is buried in the documentation. Additionally, a link to a page with more details on time zone rules and suggested forms of submission to tzdb could help guide those responsible for informing tzdb. -Brooks
On 2023-03-08 07:27, Brian Inglis via tz wrote:
Prefix "official" before "release"
I've long resisted this sort of language for tzdb. Although the IANA publishes tzdb, tzdb is by no means authoritative and I am no officer. Calling releases "official" would just put another bullseye on my back.
participants (4)
-
Brian Inglis -
Brooks Harris -
Neil Fuller -
Paul Eggert