advise on future of glibc (mktime issue)

[Jairo19@interhosting.us]

Petter Reinholdtsen wrote:

>[Jairo19@interhosting.us]
>  
>
>>After debugging I see the problem shows up because we call millions 
>>of times mktime (no way to avoid that for us). The patched glibc (I 
>>think by RH) has mktime checking for changes on the system's timezone,
>>    
>>
>
>Ah, so RedHat actually implemented this fix.  Great.  I really hope it
>make it into the upstream glibc source as well.
>
>If you want some context for this problem, have a look at
><URL:http://sources.redhat.com/bugzilla/show_bug.cgi?id=154>,
><URL:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133481>, and
><URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48184>.
>
>So what you consider a bug is considered a feature by others.
>
>Are you sure mktime() is the correct function for you to call?
>
>  
>
   Hola:

    Thank you Peter, I read all three links and yes, it seems a needed 
changed, in particular to avoid rebooting the system when the timezone 
changes on the fly, but at what cost ?. (Read the last comment on the 
first link). My program needs to call mktime millions of times, I can't 
avoid that.

    Now, the kernel keeps track of the time and the current timezone, 
why wouldn't it be keeping track of timezone changes ?, then glibc can 
just ask the kernel for the timezone instead of asking the file system, 
we can all see the performance difference.

    Back to my question, will these changes make it to the other 
distributions ?, hence becoming all slow distributions ?

    I do not really consider this a bug, but a patch with a serious 
performance hit.

   I need to know the weekday for millions of dates, I guess I could use 
a hash (I would need to find a library for that) for it, but everything 
was fine until I started using RHEL4 with the patched glibc. Any 
suggestions ?

Thanks,