Re: Bug #630: date/time storage problem: timestamp parsed

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: Bug #630: date/time storage problem: timestamp parsed
Дата
Msg-id 20020414141534.Z34216@ninja1.internal
обсуждение исходный текст
Ответ на Re: Bug #630: date/time storage problem: timestamp parsed  (Sean Chittenden <sean@chittenden.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 7.2 crash...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Bug #597: ResultSet.next() throws NullPointerException