<div dir="ltr"><div dir="ltr"><div>The problem is that currently this database is expected to change immediately, as well as vendors are expected to release asap (no expectations, just asap). Having a clear, structured release timeline, and rules that would structure such a mess, would remove the risk of such a thing to happen in the future (or at least it would attempt to organize it). Howard's or my suggestions are trying to setup such a structure. <br></div><div><br></div>@Rany Yes but that's why there should be a minimum of some sort, a minimum that has a leeway in adding the tz database, as well as for the vendors to update. That way all updates are synchronized as expected by the time people go forward with the change.<div><br></div><div>@Deborah I'm from lebanon, and this is how institutions worked with it with such a short notice: <br>- Banks didn't go forward with the change with international transactions as to not have confusion with the transactions with the international banks and their systems</div><div>- Apps that rely on cloud providers (like our case) didn't know what to work with as the vendors cannot update on the fly. We contacted AWS for our case as an example and what they told us is that there is no timeline for when the update would happen, so we need to change our codebase to take both into consideration as it might happen at any time and our code should handle the inconsistencies that appear.</div><div>- Systems that rely on 3rd party vendors (for example quickbooks for accounting, or any software the businesses are relying on) are reporting everything in the wrong date as they didn't update, and they also don't have a timeline for when the update will happen.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 27, 2023 at 8:18 PM Rany Hany via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also I forgot to mention that most vendors have a significant delay in <br>
updating their tz database, which means that even if a country provides <br>
notice to the maintainers one month prior to a change, it will not be <br>
reflected on other devices in a timely manner. This makes it even more <br>
important to issue updates in a timely manner without delay.<br>
<br>
<br>
On 3/27/23 20:13, Rany Hany via tz wrote:<br>
> While I understand your frustration with recent chaos caused by poor <br>
> planning, I have to respectfully reject your proposal for the <br>
> following reasons:<br>
><br>
> Firstly, implementing a 30-day minimum period between releases would <br>
> punish users who have outdated tzdata solely because they are ruled by <br>
> incompetent governments. While it may be easy to blame politicians for <br>
> poor planning, citizens and businesses should not be penalized for <br>
> factors beyond their control.<br>
><br>
> Secondly, deliberately making the latest tzinfo inaccurate would only <br>
> lead to more issues rather than solve them. Accurate and up-to-date <br>
> time zone information is essential for global communication and <br>
> coordination, and any intentional inaccuracy would create confusion <br>
> and further chaos.<br>
><br>
> Best<br>
><br>
> On 3/27/23 19:46, Howard Hinnant via tz wrote:<br>
><br>
>> Recent events have brought to my attention the need to put a damper <br>
>> on chaos caused by poor planning.  When governments give little <br>
>> notice to changes in time zone rules, this is not a problem that this <br>
>> group can fix, or should even try.<br>
>><br>
>> I propose a minimum period of 30 days between successive IANA tz <br>
>> database releases.  The train leaves the station no more frequently <br>
>> than once every 30 days (and will probably be less frequent).  <br>
>> Whatever information is solid before the release date makes it on the <br>
>> train.  Otherwise it can wait another 30 days (at least).<br>
>><br>
>> My recommendation is in part based on this common statement:<br>
>><br>
>>      Poor planning on your part does not constitute an emergency on <br>
>> my part<br>
>> <a href="https://www.incirlik.af.mil/News/Commentaries/Display/Article/303134/poor-planning-on-your-part-does-not-constitute-an-emergency-on-my-part/" rel="noreferrer" target="_blank">https://www.incirlik.af.mil/News/Commentaries/Display/Article/303134/poor-planning-on-your-part-does-not-constitute-an-emergency-on-my-part/</a><br>
>><br>
>> This week’s chaos isn’t unusual.  In fact it is normal, especially <br>
>> for some countries.  If they can’t be bothered to make a plan in <br>
>> advance and stick with it, I don’t see why this group of volunteers <br>
>> needs to compensate for that.  Let the politicians lie in the beds <br>
>> they make.<br>
>><br>
>> Howard<br>
>><br>
</blockquote></div></div>