Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"
From: Lew on 2 Jul 2010 10:25
Hole wrote:
> Yes, indeed I've just came out with the same thing...it's the DST
> problem.

The problem is not DST, it's the failure to account for it.

OK, DST is a problem, but a social one. Our job as programmers is to
accept and deal with it.

> My TZ is GMT+1...

The EU adjusts to DST on the last Sunday in March (the 29th in 2009)
at 1 a.m. GMT, which was 2 a.m. in your time zone.

> Now, how to set a TZ in order to not taking into account the DST? I
> would deal with a TZ free of DST issue...

Set the TZ to GMT!

Again, it is our job as programmers to be educated about time zones.
Time for you to do some reading!

--
Lew
From: markspace on 2 Jul 2010 13:49
Lew wrote:
>
> The problem is not DST, it's the failure to account for it.
>
> OK, DST is a problem, but a social one. Our job as programmers is to
> accept and deal with it.


Instead of accept it, why not engineer it away? I'm starting to think
that a VerySimpleDate class, which has no DST or time zone component,
would be a very useful thing. It should assume a 24 hour clock, and
include basic leap year calculations, and that's it.

To many surprises and gotchas show up if you don't do time zone
information just right, and it's hard to verify that you've done this
correctly for all time zones. If I want to test that my entire app uses
time zones correctly, how do I do that? Set my test harness to each
time zone and run a full app test? That's kind of ridiculous, but it's
need to catch any error in converting from one time zone to another
anywhere in the app. One missed "GMT" anywhere in the app and it'll
fail, but I'm not sure that I've got every "GMT" where I need it until I
test all possible date, time, and TZ combinations!


From: Lew on 2 Jul 2010 14:23
Lew wrote:
>> The problem is not DST, it's the failure to account for it.
>
>> OK, DST is a problem, but a social one.  Our job as programmers is to
>> accept and deal with it.
>

markspace wrote:
> Instead of accept it, why not engineer it away?  I'm starting to think
> that a VerySimpleDate class, which has no DST or time zone component,
> would be a very useful thing.  It should assume a 24 hour clock, and
> include basic leap year calculations, and that's it.
>

If the app has to deal with humans, and it involves date or time input
or outputs, then you must deal with time zones.

For example, I worked on a large application where the business rules
had to verify that a transaction was submitted within seven calendar
days of its deadline. There was no way to avoid dealing with Daylight
Saving Time because that was part of the business requirement.

It is our job as programmers to accept and deal with it.

--
Lew
From: Lew on 2 Jul 2010 15:19
markspace wrote:
>> Instead of accept it, why not engineer it away?  I'm starting to think
>> that a VerySimpleDate class, which has no DST or time zone component,
>> would be a very useful thing.  It should assume a 24 hour clock, and
>> include basic leap year calculations, and that's it.
>

It occurs to me belatedly that Java already has such a type:
<http://java.sun.com/javase/6/docs/api/java/util/Date.html>

--
Lew
From: Jean-Baptiste Nizet on 2 Jul 2010 16:40
Lew a �crit :
> markspace wrote:
>>> Instead of accept it, why not engineer it away? I'm starting to think
>>> that a VerySimpleDate class, which has no DST or time zone component,
>>> would be a very useful thing. It should assume a 24 hour clock, and
>>> include basic leap year calculations, and that's it.
>
> It occurs to me belatedly that Java already has such a type:
> <http://java.sun.com/javase/6/docs/api/java/util/Date.html>
>

Exactly my thought : a Date is a number of millis since 1st January
1970. While you don't try to display it in a human readable format, you
don't have problems with time zones.

JB.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"