Re: Best practices: Handling Daylight-saving time

Not exactly...

Here is a scenario I ran in to with collecting bandwidth usage and
displaying it back in graph form to customers.

You can store the timestamps in GMT, but the customer wants to see when
spikes happen in his localtime, which most likely has DST. So twice a
year, you are either compressing two hours of bandwidth usage into one,
or the opposite, stretching one hour in to two, which of course produces
somewhat odd looking graphs during that time.

Besides making note of DST on the graph so the customer can see it, I
haven't found a elegant solution to this problem.

On Fri, 2005-03-11 at 12:19 -0500, Christopher Browne wrote:
> csegyud(at)vnet(dot)hu (Együd Csaba) wrote:
> > 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?
>
> Don't use DST.
>
> Use GMT/UTC.
>
> That makes the issue go away.
--
Mike Benoit <ipso(at)snappymail(dot)ca>