Re: Best practices: Handling Daylight-saving time

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: Együd Csaba <csegyud(at)vnet(dot)hu>, pgsql-general(at)postgresql(dot)org
Subject: Re: Best practices: Handling Daylight-saving time
Date: 2005-03-11 18:22:06
Message-ID: 200503111022.06872.scrawford@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday 11 March 2005 6:25 am, Együd Csaba wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24
> system. Where should it be handled: on the server side or on the
> client side? And how could I (at all could I???) make it
> transparent?
>
> Or we must bow to the fact that twice a year there are two unusable
> hours? If it cannot be solved technically, than it is acceptable,
> but if there is a chance to do it, I'd like to try it.
>
> Our system stores 200-1000 measured data per minute, comming from
> substations. The substations clock is synchronized periodically as
> well. When the DST is switched there is 1 hour of data missing (or
> overlapped). Certainly the client machines are autmatically
> adjusted for the DST.

First, at point in time is a point in time. You might call it
2005-03-11 01:02:03.12345 GMT or you might represent it in any other
time zone with or without Daylight Saving Time (or European Summer
Time or...) but it is still the same point in time.

Your assertion about unusable hours is incorrect. Rather, if you have
this problem then you aren't sending/storing the time stamp data
completely/correctly.

Here on the West Coast of the US in the spring the time simply moves
seamlessly and continuously from 01:59:59 PST to 03:00:00 PDT.
Similarly in the fall it goes from 01:59:59 PDT to 01:00:00 PST. If
you throw away the time zone the you will naturally have problems.

The localization in both *nix and PostgreSQL will display the times
just fine based on whether or not they are in standard or daylight
time. (Try "select now();" and "select now() + '1 month'::interval;"

Whether you choose to fix things by specifying complete timestamps,
standardize on GMT, use unix timestamps, etc. is up to you. It will
all work fine if both ends use the same convention and you don't drop
critical parts of the timezone information.

Side note: if you are using cron/at to schedule your data collection
then you need to investigate the behaviour of your versions of those
programs and compare it to your desired outcome.

Cheers,
Steve

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Fuhr 2005-03-11 18:33:31 Re: Unique Indexes
Previous Message Andrew Sullivan 2005-03-11 18:08:50 Re: Slony uninstall info/warning