On Tuesday 21 May 2002 09:23 am, Thomas Lockhart wrote:
> > While I don't agree with the standard, trying to be standard isn't really
> > a 'problem'. Relying on a side-effect of a nonstandard call is the
> > problem.
> In my mind no one associated with glibc gets high marks for anything
> having to do with this change. It is unbelievably short sighted.
Oh, I most certainly agree with you on this Thomas. The glibc people are just
being adamant about it being 'standard.' And I certainly didn't mean to step
on your toes, either -- as I can tell this is a sore point for you. I'm just
trying to see what, if anything, we can do about it.
> > Can we pull in the BSD C library's mktime()? OR otherwise utilize it to
> > fit this bill?
> Maybe, but probably forcing a *really* annoying code fork or patch to
> get the entry points to play nice with glibc. We'll also need to figure
> out how to manage the time zone database and how to keep it in sync.
> This is a seriously big problem, and we'll need to research what to do
> next. One possibility is to strip out all string time zone behavior and
> support only the SQL date/time standard, which specifies only numeric
> offsets and ignores real-world time zone usage and behaviors. Hmm, IBM
> contributed to that standard too, maybe the common thread is not a
> coincidence.
Well, the existing behavior, according to my first read of the code, is to
assume UTC if the time_t is predicted to be out of range. There is a macro
for this, I see. And the problem is that the out-of-range condition is
happening at a different place. I don't like this thought, but the most
consistent, least-common-denominator tack would to be flag anything prior to
epoch as out-of-range, even if the underlying calls can handle negative
time_t. I don't like that one whit. But I like inconsistent data even less.
> The new glibc behavior is really disappointing. Help and ideas are
> appreciated; reimplementing an entire date/time system may be a lot of
> work.
Well, it was good foresight on your part to put all the mktime stuff in the
one place. I'm going to go through it and see if I understand what I'm
looking at first.
But I see a couple of possibilities that we can control:
1.) Have configure test for broken mktime and sub our own mktime in that case
(if this is even possible -- while the various BSD's have mktime and friends,
how difficult is it going to be to unshackle that from a BSD kernel
underneath -- I've not looked at the code for OpenBSD's mktime (which I have
on hand), but I guess I will take a look now);
2.) Rewrite our stuff to not depend on any mktime, and thus be more portable
(perhaps?).
But, in any case, I didn't mean to step on your toes by any of my comments; I
completely agree with you that glibc and the ISO C standard cited are daft in
this.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
