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.
@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.
@Deborah I'm from lebanon, and this is how institutions worked with it with such a short notice:
- 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
- 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.
- 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.