Hi John,
On 21/01/2008, at 10:54 PM, John Pollard wrote:
Solved! ... pass time zone in user.timezone, don't set in code
Brute force approach ay. The only problem this poses is that you can
no longer do NSTimeZone.systemTimeZone() and get anything other than
GMT.
Thanks for going into some detail in your reply.
No worries. I'm also needing to double check my own app for this
stuff at the moment so it's good timing :-)
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.
Great. Easily solved.
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.
Is that because of previously mentioned static initialisers? Lazy
initialisation /should/ do the trick unless I've missed something or
there's a bug somewhere.
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.
Interesting. Possible. Strange. Would have to peek in on the
deserializers to check... which I need to do for Axis/WO as I've got
a 1hour shift happening from remote app to mine for non-dst
timestamps that I'm tracking down atm.
Note, there's also a list of properties that are worth checking out
with regards to your jdbc connection.
Search for 'timezone' in the following:
http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-
configuration-properties.html
This is also helpful:
http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html
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).
Nice you've got it working. If you do find you need a handle on the
system's timezone (which is usually a nice-to-have on the client
side) I'd be digging deeper... depending on other priorities of course.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
