This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: advise on future of glibc (mktime issue)

Petter Reinholdtsen wrote:


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:>, and

So what you consider a bug is considered a feature by others.

Are you sure mktime() is the correct function for you to call?


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 ?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]