[PATCH 2/2 v2] compat/timegm: new compat function for systems lacking timegm()

[John Keeping]

On Thu, Apr 04, 2013 at 04:59:50PM +0200, Jason A. Donenfeld wrote:
> On Thu, Apr 4, 2013 at 4:46 PM, John Keeping <john at keeping.me.uk> wrote:
> >
> > I decided not to do that based on this message:
> >
> >
> > http://lists.samba.org/archive/samba-technical/2002-November/025578.html
> >
> > but of course it doesn't provide any actual reason for why that version
> > doesn't work.
> >
> 
> Aye yie yie. Time handling functions are a mess. I just went looking at how
> glibc [1] and uclibc [2] actually go about doing things, and it's a real
> mess in there. Looks like the replacement function in the patch might not
> be completely correct.
> 
> [1] http://git.uclibc.org/uClibc/tree/libc/misc/time/time.c#n2330
> [2]
> http://sourceware.org/git/?p=glibc.git;a=blob;f=time/mktime.c;h=e75132c2e457af4b5629eef302c0d6dac15fef5c;hb=HEAD#l348
> (uclibc gets bonus points for using cgit)
> 
> >
> > We only use timegm in week calculations, where we do:
> >
> >     time_t t = timegm(tm);
> >     t = <new value>;
> >     gmtime_r(&t, tm);
> >
> > so I wonder whether it would be equivalent to use mktime/localtime_r
> > instead of timegm/gmtime_r.
> >
> 
> 
> gmtime(timegm(tm)) == tm
> 
> and
> 
> localtime(mktime(tm)) == tm
> 
> 
> So I can't imagine there'd be a problem with just replacing those functions.

Actually, there is a potential for a difference here, since
gmtime/timegm will not have daylight savings adjustments but
localtime/mktim might.  I suspect this means that the calculation we do
of adding/subtracting a week from the time could end up being an hour
out after converting back to struct tm.

I'm not sure what the best way to tackle this is, especially if there is
not a simple, correct replacement function that we can use.