Re: [PATCH 10/10] timegm: add portable implementation (Solaris support)

[Tomi Ollila <tomi.ollila@iki.fi>]

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