On May 27, 2:58pm, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: [tz] problems with unsigned 32-bit time_t coming up | I vaguely recalled someone reporting trouble with the tz database | on NetBSD or some other BSD in the past few months. The gist of it | was that this platform has 32-bit 'long' and 64-bit 'time_t', and | the tz code didn't play nicely on such a system. | | To try to catch this sort of thing I'd like to add support for trying | different time_t types, even if they disagree with the system's | time_t. I'll send a couple of proposed patches to the list to do that. | I'll then follow up with a report of a bug in the reference | implementation that is discovered by the patches, when configured | to run with an unsigned 32-bit time_t. This isn't the NetBSD | problem, but hey! at least there's an easy-to-run test | case that illustrates the bug. There have been two major bugs I can remember relating to NetBSD's 64 bit time_t. 1. Sun's openjdk mercurial repository got corrupted when I committed some code from a 32 bit system with 64 bit time_t. Talking about trusting the binary payload!?!? I believe it was fixed and I hope it was done properly. 2. Postgres assumed the sizeof(time_t) == sizeof(long), and when systems upgraded to NetBSD-6 and recompiled postgres (because the compatibility code just works fine), it exposed that postgres bug and none of the databases would load. To my knowledge both bugs have been fixed. I don't know of any others? Does anyone else? Unfortunately I don't know how to catch those application errors easily, specially when they use casts... christos