Re: locations of DST information
Re: locations of DST information
- Subject: Re: locations of DST information
- From: "Mr. Pierre Frisch" <email@hidden>
- Date: Mon, 28 Jan 2008 08:19:52 -0800
NSTimeZone and NSTimestampFormatter are deprecated because of their
reliance on internal copy of the time zone information. They do not
provide any services not provided by the base Java classes TimeZone
and SimpleDateFormat. Whether you are working with 5.3 or 5.4 please
move out of those classes. To my knowledge 5.3 only uses them for GMT
time/date conversion which is safe, and I think 5.4 has no references
to them.
The base Java classes rely on the time zone info embedded in the Java
VM which is regularly updated. If you need some really urgent update
there is a Sun tool to load the latest and greatest. For more
information see: http://docs.info.apple.com/article.html?artnum=305129
Pierre
--
Pierre Frisch
email@hidden
On Jan 27, 2008, at 23:06, Lachlan Deck wrote:
On 28/01/2008, at 5:44 PM, Art Isbell wrote:
On Jan 27, 2008, at 8:10 PM, Lachlan Deck wrote:
What I meant was that I assumed that, as I'm seeing the correct
behaviour on my development machine with WO5.3, that I would have
thought that by embedding all system frameworks for 5.3 in the app
that the behaviour would continue to be correct on deployment.
Seems like a valid assumption to me as far as the NSTimeZone is
concerned *if* none of the WO 5.4 frameworks containing time zone
info is being loaded (i.e., if the class paths exclude all WO 5.4
frameworks and jars). But if the JVM time zone info differs
between the dev and deployment machine, then Java TimeZone
calculations could differ.
Yeah, 5.4 is not in the picture at all, for the moment, whether in
dev or deploy.
I'd make copies of the original WO jars, follow the time zone
info update procedure outlined in the KBase article, and give it
a whirl. The worst that could happen would be that you'd have to
restore the original jar versions.
Yeah, that's not under my control... (but certainly can be fixed),
I was just hoping to not have to rely on the timing of that
happening, pun intended :-)
The time zone info in the WO frameworks isn't updated unless the
frameworks are updated. And even then, the time zone info might
not reflect recent changes in certain parts of the world. So some
manual time zone info updating between WO updates might be
necessary to keep time calculations accurate.
I seem to remember there being a System Update for WO 5.3 last year
that included dst updates, unless I'm mistaken. I know there was for
java itself, but I just can't remember. I guess I could always
update my dev machine anyway and see if that has any effect.
Nevertheless, updating the java zone info will be a necessary step
(or getting this up on another more recent box) anyway.
I'm also considering whether or not to use ant to deploy with the
app a snapshot of the zoneinfo(s) for certain zones so as to ensure
that what's getting saved/retrieved is not offset incorrectly. But
that's a hassle I can avoid if I can get the apps over to another box.
Thanks.
with regards,
--
Lachlan Deck
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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