Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"
From: Arne Vajhøj on 4 Jul 2010 19:49
On 02-07-2010 13:49, markspace wrote:
> 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!

Is it that much harder to check if TimeZone is provided everywhere
than to check if VerySimpleDate is used instead of Date/Calendar
everywhere?

Arne

From: Lew on 4 Jul 2010 20:31
markspace wrote:
>> To[o] 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!

Arne Vajhøj wrote:
> Is it that much harder to check if TimeZone is provided everywhere
> than to check if VerySimpleDate is used instead of Date/Calendar
> everywhere?

If you layer and encapsulate your design properly, then it isn't necessary to
look the "entire" app for time zone but just those places that bring the data
in to GMT and the ones that express it out to a time zone. The suggestion
that you need the string "GMT" in a zillion places is ill founded.

For example, in a system with a database you store all dates and times in the
DB as Zulu time, and call out the local time at the local client and only
there, and in specific, well-documented spots at that.

Since the so-called "VerySimpleDate" is nothing more nor less than the
familiar 'java.util.Date', which by design holds values in Zulu time, the
problem is nearly completely solved for us already for Earth-based
applications. (Galactic time zones will require some adjustment.)

--
Lew
From: Hole on 5 Jul 2010 03:52
On Jul 5, 2:31 am, Lew <no...(a)lewscanon.com> wrote:
> markspace wrote:
> >> To[o] 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!
> Arne Vajhøj wrote:
> > Is it that much harder to check if TimeZone is provided everywhere
> > than to check if VerySimpleDate is used instead of Date/Calendar
> > everywhere?
>
> If you layer and encapsulate your design properly, then it isn't necessary to
> look the "entire" app for time zone but just those places that bring the data
> in to GMT and the ones that express it out to a time zone.  The suggestion
> that you need the string "GMT" in a zillion places is ill founded.
>
> For example, in a system with a database you store all dates and times in the
> DB as Zulu time, and call out the local time at the local client and only
> there, and in specific, well-documented spots at that.
>
> Since the so-called "VerySimpleDate" is nothing more nor less than the
> familiar 'java.util.Date', which by design holds values in Zulu time, the
> problem is nearly completely solved for us already for Earth-based
> applications.  (Galactic time zones will require some adjustment.)
>

Hi there,

Since the DST is both a political and an output format issue, it's got
some sense to set the timezone in a DateFormatter, but I'd have some
concerns.

However, I read that util.Date is ever an UTC date . But if you use
the DateFormatter.parse to parse a string representing an UTC date and
your formatter has a Timezone!=GMT, then your java.util.Date object
isn't a UTC date.
Is it right? If it is, what does tha statement "java.util.Date is
always an UTC date" mean?


From: Lew on 5 Jul 2010 04:29
Hole wrote:
> Since the DST is both a political and an output format issue, it's got
> some sense to set the timezone in a DateFormatter, but I'd have some
> concerns.
>
> However, I read that util.Date [sic] is ever an UTC date . But if you use
> the DateFormatter.parse [sic] to parse a string representing an UTC date and
> your formatter has a Timezone!=GMT, then your java.util.Date object
> isn't a UTC date.
> Is it right?

No.

The resultant 'Date' will be set to the UTC time corresponding to the
'TimeZone' actually used. In other words, you force the string to represent
the 'TimeZone' actually used. In your example, it is the string that isn't a
UTC date, not the 'Date'.

> If it is, what does tha statement "java.util.Date is
> always an UTC date" mean?

Just what it says.

--
Lew
From: Hole on 5 Jul 2010 08:06
On 5 Lug, 09:52, Hole <h0lefor...(a)gmail.com> wrote:
> On Jul 5, 2:31 am, Lew <no...(a)lewscanon.com> wrote:
>
>
>
>
>
> > markspace wrote:
> > >> To[o] 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!
> > Arne Vajhøj wrote:
> > > Is it that much harder to check if TimeZone is provided everywhere
> > > than to check if VerySimpleDate is used instead of Date/Calendar
> > > everywhere?
>
> > If you layer and encapsulate your design properly, then it isn't necessary to
> > look the "entire" app for time zone but just those places that bring the data
> > in to GMT and the ones that express it out to a time zone.  The suggestion
> > that you need the string "GMT" in a zillion places is ill founded.
>
> > For example, in a system with a database you store all dates and times in the
> > DB as Zulu time, and call out the local time at the local client and only
> > there, and in specific, well-documented spots at that.
>
> > Since the so-called "VerySimpleDate" is nothing more nor less than the
> > familiar 'java.util.Date', which by design holds values in Zulu time, the
> > problem is nearly completely solved for us already for Earth-based
> > applications.  (Galactic time zones will require some adjustment.)
>
> Hi there,
>
> Since the DST is both a political and an output format issue, it's got
> some sense to set the timezone in a DateFormatter, but I'd have some
> concerns.
>
> However, I read that util.Date is ever an UTC date . But if you use
> the DateFormatter.parse to parse a string representing an UTC date and
> your formatter has a Timezone!=GMT,  then your java.util.Date object
> isn't a UTC date.
> Is it right? If it is, what does tha statement "java.util.Date is
> always an UTC date" mean?

For everyone is interested in the TimeZone thing:

If your original poor UTC string date passes unharmed any "silent &
transparent" conversion from a TimeZone to your local default one and
you have to insert that Timestamp in your database, remember to use
the method CallableStatement.setTimestamp() that accepts a Calendar
instance with the proper TimeZone adjusted, since the JDBC Driver will
use your default TimeZone when it constructs the TIMESTAMP.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"