This is the mail archive of the
mailing list for the glibc project.
Re: advise on future of glibc (mktime issue)
- From: "Jairo19 at interhosting dot us" <jairo19 at interhosting dot us>
- To: Petter Reinholdtsen <pere at hungry dot com>
- Cc: libc-alpha at sources dot redhat dot com, jairo19 at interhosting dot us
- Date: Tue, 07 Jun 2005 11:51:25 -0400
- Subject: Re: advise on future of glibc (mktime issue)
- References: <42A5B0C4.email@example.com> <20050607145445.GF9207@saruman.uio.no>
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
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
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
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