Using the tzdb: What's actually changed
Dear all, I see lots and lots of people who seem to be running applications that care about pre 1970 timestamps and don't use backzones, or seem to ignore links. Well, if you ignore links you deserve what you get: it's been documented that zones may become links. The size of tzdb has already caused problems for some embedded devices. Post-1970 correctness only strikes me as very reasonable. Applications that need more should use backzones, and this has been true for years. If you care about the truth of what time something happened, and it was recorded in local time, and the zone that it was in might need to get split in the future, and that split could change when the time was or other times you care about then the database isn't your problem, reality is. I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist. Remember, you're only affected if you deal with pre-1970 timestamps. Sincerely, Watson -- Astra mortemque praestare gradatim
On Tue, 28 Sep 2021, Watson Ladd via tz wrote:
I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist.
PHP has millions of users, can you guarantee that it won't be a problem for any of them? cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug
On Tue, Sep 28, 2021 at 8:43 AM Derick Rethans via tz <tz@iana.org> wrote:
On Tue, 28 Sep 2021, Watson Ladd via tz wrote:
I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist.
PHP has millions of users, can you guarantee that it won't be a problem for any of them?
cheers, Derick
-- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug
Sorry but how is that a problem for tzdb? It's pretty well established that the primary focus of the database has to do with maintaining the integrity of data post-1970. If any downstream application or language is impacted by an action taken in the spirit of that, it's not tzdb's problem. When the requirement arises for pre-1970s timezone data, the backzone files do exist and there have been multiple strategies discussed at this point on how to use the ones that might be needed.
On 28.09.21 18:39, Anthony Hernandez via tz wrote:
Sorry but how is that a problem for tzdb? It's pretty well established that the primary focus of the database has to do with maintaining the integrity of data post-1970.
If any downstream application or language is impacted by an action taken in the spirit of that, it's not tzdb's problem.
When the requirement arises for pre-1970s timezone data, the backzone files do exist and there have been multiple strategies discussed at this point on how to use the ones that might be needed.
Can we agree that this is a good discussion to have, because it may be worth this group deciding what should be the TZDB's problem. I personally appreciate Derick's concern for those who are using PHP (and his desire not to be inundated with email ;-). But it may take us some time to sort. Eliot
On Tue, 28 Sep 2021, Anthony Hernandez via tz wrote:
On Tue, Sep 28, 2021 at 8:43 AM Derick Rethans via tz <tz@iana.org> wrote:
On Tue, 28 Sep 2021, Watson Ladd via tz wrote:
I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist.
PHP has millions of users, can you guarantee that it won't be a problem for any of them?
Sorry but how is that a problem for tzdb?
It will become a problem when I mention to PHP users that PHP's policy has always been "we bundle what tzdata does, if you have problems with the data, complain there", which likely created more Kiev/Kyiv discussions that I would have liked to see.
It's pretty well established that the primary focus of the database has to do with maintaining the integrity of data post-1970.
It's pretty well established for people on this list. I don't have the problem with *focussing* on post-1970 data. I have a problem with people using pre-1970 data succesfully, with likely accurate data, that are then forced to use pre-1970 that is demonstratively wrong.
If any downstream application or language is impacted by an action taken in the spirit of that, it's not tzdb's problem.
When the requirement arises for pre-1970s timezone data, the backzone files do exist and there have been multiple strategies discussed at this point on how to use the ones that might be needed.
PHP's users do not have the choice which data to pick. It is either what I bundle through timelib, or what Linux distrbutions bundle as OS zoneinfo files. They can't make the choice of whether to use backzone, packrat, or any other fork of the data. Nor would they even have the slightest idea that these things even exist. By replacing known-mostly-good data with known-wrong data you pretty much sabotage their use cases. cheers, Derick
On Tue, Sep 28, 2021, 8:43 AM Derick Rethans <derick@derickrethans.nl> wrote:
On Tue, 28 Sep 2021, Watson Ladd via tz wrote:
I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist.
PHP has millions of users, can you guarantee that it won't be a problem for any of them?
PHP can either vendor a version of tzdb with backzone or let systems that ship their own packages make their own decisions, and deal with the fallout of maintainer choices. That dichotomy has always existed. Remember weak keys?
cheers, Derick
-- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug
participants (4)
-
Anthony Hernandez -
Derick Rethans -
Eliot Lear -
Watson Ladd