Re: Bug #630: date/time storage problem: timestamp parsed - Mailing list pgsql-bugs

From Sean Chittenden
Subject Re: Bug #630: date/time storage problem: timestamp parsed
Date
Msg-id 20020414141534.Z34216@ninja1.internal
Whole thread Raw
In response to Re: Bug #630: date/time storage problem: timestamp parsed  (Sean Chittenden <sean@chittenden.org>)
List pgsql-bugs
> Ugh, I'm too tired to file a gdb report:
>=20
> 1490                    t =3D mktime(tmp);
> (gdb)=20
> 1491                    fprintf(stderr, "%p\n", t);
> (gdb) print t
> $7 =3D -1
>=20
> Good call Tom.  ...  I'm going to file a PR w/ FreeBSD.

The FreeBSD folk are absolutely adamant about having mktime() no
compensate for deadzones between DST shifts and they insist that the
application handle this.  Someone's off looking at how other OS'es
handle this, but this could be an arduous battle on that front.  <:~)

> I know the attached patch is something of a hack, but it works.  I'm
> not totally wild about altering the original time object, but I
> don't know that I have a choice in this case.  Does anyone switch
> timezones and only adjust their clocks by anything other than 60min?
> I seem to recall that happening in a few places, but the patch isn't
> any worse than where we are now. ::shrug:: This look like an okay
> patch?

Are there any objections to the following?  Instead of returning 0 or
utc, I could have it raise an error.  Would that be acceptable?  -sc

> Index: src/backend/utils/adt/datetime.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
> retrieving revision 1.88
> diff -u -r1.88 datetime.c
> --- src/backend/utils/adt/datetime.c    2002/02/25 16:17:04    1.88
> +++ src/backend/utils/adt/datetime.c    2002/04/10 06:12:45
> @@ -1439,6 +1439,7 @@
>  DetermineLocalTimeZone(struct tm * tm)
>  {
>      int            tz;
> +    time_t            t;
>=20=20
>      if (HasCTZSet)
>          tz =3D CTimeZone;
> @@ -1463,7 +1464,23 @@
>          /* indicate timezone unknown */
>          tmp->tm_isdst =3D -1;
>=20=20
> -        mktime(tmp);
> +        t =3D mktime(tmp);
> +        if (t =3D=3D -1)
> +        {
> +            /* Bump time up by an hour to see if time was an
> +             * invalid time during a daylight savings switch */
> +            tmp->tm_hour +=3D 1;
> +            t =3D mktime(tmp);
> +
> +            /* Assume UTC if mktime() still fails.
> +             *
> +             * If mktime() was successful with the adjusted time,
> +             * adjust the real time object. */
> +            if (t =3D=3D -1)
> +                return 0;
> +            else
> +                tm->tm_hour +=3D 1;
> +        }
>=20=20
>          tm->tm_isdst =3D tmp->tm_isdst;
>=20=20

--=20
Sean Chittenden

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.2 crash...
Next
From: Bruce Momjian
Date:
Subject: Re: Bug #597: ResultSet.next() throws NullPointerException