Re: NSTimestamp mapped to DATE for mysql
Re: NSTimestamp mapped to DATE for mysql
- Subject: Re: NSTimestamp mapped to DATE for mysql
- From: John Pollard <email@hidden>
- Date: Mon, 21 Jan 2008 11:54:57 +0000
Hi Lachlan,
Solved! ... pass time zone in user.timezone, don't set in code
Thanks for going into some detail in your reply.
On 19 Jan 2008, at 12:32, Lachlan Deck wrote:
On 18/01/2008, at 2:44 AM, John Pollard wrote:
Many thanks for your reply. I do do all the default timezone
setting in my application, client and server side. However, I
found SimpleDateTimes used for conversions don't use the system
timezone and you also have to set it on these explicitly. I
currently set it to London/Europe.
Hmm. Firstly, are you certain you're setting the runtime TimeZone
for java correctly? Because SimpleDateFormat will use a Calendar
initiated with TimeZone.getDefault(), and Locale for that matter.
I was setting it much as you do in your code, but I have now worked
out that my SimpleDateFormat was being statically initialised before I
was setting the default TimeZone. That wasn't my main problem exactly,
but does explain why I thought wrongly that SimpleDateFormat wasn't
using the default time zone.
Secondly, setting it to London/Europe for parsing/formatting dates
is your problem. This is the rule of thumb that works for working
with dates (as opposed to datetimes): 'Dates are dates are dates.
They do not have timezones. They are like constants. They don't
change.' My birthdate, for example, doesn't change should I travel
to somewhere with a different timezone.
The rest of your reply mainly drills home the perils of storing a date
with no time in conjunction with using a non GMT timestamp. That
message has certainly got through.
I have now finally solved this. Setting the time zone in code on both
server and client sides of my application was not enough. It was the
first thing I did in code, but apparently not soon enough. It may be
that my own experience with my statically initialised SimpleDateFormat
is a clue to what is happening, but some underlying WO code still
operates in the wrong time zone (BST dates arrive back on my client 1
hour shifted). So somehow my system default time zone (Europe/London)
was still getting a hold on parts of my application.
The solution...
Pass the following to the java VM for both my server and client side
applications:
-Duser.timezone=GMT
So whatever bits of my WO app were picking up the default time zone
from my box (Europe/London), now don't, they use GMT instead and it
works. I will strip out all my attempts to set the timezone in code as
they appear to miss the boat (note Java Client application).
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden