Thread

1. Daylight savings

   Justin Clift <aa2@bigpond.net.au> — 2001-05-03T07:03:11Z

   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
   
   

2. Re: Daylight savings

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-04T22:27:38Z

   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
   
   

3. Re: Daylight savings

   newsreader@mediaone.net — 2001-05-04T23:22:03Z

   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]'
   
   

4. Re: Daylight savings

   Justin Clift <justin@postgresql.org> — 2001-05-05T02:11:45Z

   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