On Mon, Nov 05 2012, Blake Jones wrote: >> Yet another idea for an alternative. Compile by entering 'sh xtimegm.c' >> and then run ./xtimegm >> >> Simple cases seems to work. Dst change may (or then may not) give one >> hour difference to the expected. The test "coverage" could be easily >> expanded to that ;) >> >> Hmm, I also found this: >> http://lists.gnu.org/archive/html/bug-gnulib/2003-09/msg00004.html >> which does 2 mktime's and one gmtime_r (without allocating tg!)... >> Pick any of these 3 -- or something different (e.g. less NIH if there is) > > Of these two, I would probably lean slightly toward the latter, in that > it relies more on libc for the time zone handling logic. > > But in general, this seems to me like a case where an explicit > implementation like mine is less prone to failure, because it doesn't > need to worry about time zones at all. Good point. > The other approaches rely on > letting libc do all the hard work of time zone manipulation, and then > reading the tea leaves to find a way to undo it. Did you look at the gnu libc version -- I bet it is pretty hairy... > I would guess that if > some change in the time standards is going to break one of these > implementations, it's going to be some new time zone specification, not > a change in the number of days in a month. :) > > For what it's worth, I used the attached program to test my > implementation, and it passed. Thanks, It's nice to see your simple implementation passes these tests... Just for curiosity: What do you think lacks in your timegm() that it could not be promoted as 'complete timegm() solution'. In any way, including this timegm() function in compat suits me fine. > > Blake > Tomi