Thread: Daylight savings

Hi all,

I'm wondering if anyone has scripts or knows of any tools which will detect
the next DST change, and setup a cronjob to be run just before it?

This is so we can have certain types of data which are stored in the database
as localtime, updated to still be correct during DST and after.

At present I'm considering running a mismash of zdump, perl, psql, etc, and
I'm kind of hoping there's already something out there.

Regards and best wishes,

Justin Clift

Justin Clift <aa2@bigpond.net.au> writes:
> This is so we can have certain types of data which are stored in the
> database as localtime, updated to still be correct during DST and
> after.

This sounds awfully ugly.  Can't you design the data representation so
that no such kluge is needed?  Most of the PG date/time types store in
GMT internally, so that there shouldn't be a problem...

            regards, tom lane

On Thu, May 03, 2001 at 05:03:11PM +1000, Justin Clift wrote:
> Hi all,
>
> I'm wondering if anyone has scripts or knows of any tools which will detect
> the next DST change, and setup a cronjob to be run just before it?

I don't know what you mean by "detect"
but perl's localtime can tell you whether
it's DST or not

$ perldoc -f localtime

What you can do is something like

$ perl -e '@a=localtime(time + 86400);print "It will be daylight saving time in 24 hours! Do something" if $a[8]'

Hi Tom,

Agreed, it's very ugly.  Unfortunately the product has been mostly
developed relying on some fields being used in ways I'd never considered
someone would do.  Too late and not enough time to get it changed, so
I'm having to devise a workaround.

:-(

Regards and best wishes,

Justin Clift

Tom Lane wrote:
>
> Justin Clift <aa2@bigpond.net.au> writes:
> > This is so we can have certain types of data which are stored in the
> > database as localtime, updated to still be correct during DST and
> > after.
>
> This sounds awfully ugly.  Can't you design the data representation so
> that no such kluge is needed?  Most of the PG date/time types store in
> GMT internally, so that there shouldn't be a problem...
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi