Zefram wrote:
I've posted a patch more than one that would make the 400 year hack more robust, and it seems to have got lost each time. It's sitting on a branch in my public git repo.
Sorry about that, it was still in my inbox. I revisited it today. It inserts an artificial mark into the zic binary file so that, for zones in which POSIX TZ strings cannot support time stamps into the indefinite future, a consumer of the binary file can more easily determine where its data are valid. This jogged my brain to look two other items in my inbox that are relevant and less problematic. I fixed these and pushed the fixes into the experimental github. First, "Record that San Luis is at UTC-3, not UTC-4 with perpetual DST." <http://mm.icann.org/pipermail/tz/2013-September/019996.html> adjusts Argentina/San_Luis to not have a weird setting of perpetual DST indefinitely into the future, a setting that POSIX TZ strings cannot represent. Second, "Support time stamps past 2038 in zones like America/Santiago" <http://mm.icann.org/pipermail/tz/2013-September/020013.html> fixes zic to generate TZ strings that work into the indefinite future for almost all zones where this was a problem, thus removing the need for the artificial mark in these zones. There's one remaining zone which has the problem, namely Asia/Tehran, but I don't think your 400-year change fixes it. So, I'm hoping that your fix is no longer needed, in that the other two patches have fixed things in a different way. Anyway, thanks for bringing this up, as it prompted fixes for the problems in the database or the way it's processed on POSIX platforms.