Re: TimeZoneProvider off the Jdk TimeZone data

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TimeZoneProvider off the Jdk TimeZone data

Jawad
Brian S O'Neill <bronee <at> gmail.com> writes:

>
> A big reason why Joda has its own provider is for performance. DateTime
> does not pre-calculate field values in advance, and so it will apply a
> time zone offset each time a field value is requested. Joda's time zone
> provider caches offsets, which is only possible because DateTimeZone has
> the nextTransition and previousTransition methods. Implementing these
> methods on top of java.util.TimeZone is nearly impossible.
>
> If you decide to simply not implement the next/previous transition
> methods, you can probably get by, since these methods are not used
> internally by anything other than the current provider. Be prepared to
> see a performance impact, however.
>
> vijay konnackal wrote:
> > Now that Sun's tzupdater tool is out, it might be worthwhile to have a
> > Provider that is driven off the Jdk's timezone data.
> >
> > * Don't have to update both Joda and Jdk's for a DST change. When the
> > deployment is on hundreds of dev and production servers it does make a
> > difference.
> > * It will be end of the nasty surprises if Joda and Jdk happen to be
> > on different versions of Olson data and conversion happen from one to
> > the other (for third party APIs including various specs) . We have
> > been bitten by this before.
> >
> > Is anybody working on such a solution? If yes, have you faced any
> > issues with data compatibility.
> >
> > Thanks, Vijay

I think vijay raises a valid question. Why can't we have a provider that instead
of maintaining its own data store, reads it from the JDK timezone data and
caches it? In this case the cache will not get updated until the server is
restarted but for most java based products (like ours) we stop the server anyway
before updating the JDK its running off.

JODA is an excellent API however I am reluctant to use it because then every
time a customer updates their JDK, we would have to release a patch version just
to keep the timezone updates in sync.

Jawad.


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TimeZoneProvider off the Jdk TimeZone data

jodastephen
On 21 January 2012 10:31, Jawad <[hidden email]> wrote:

> Brian S O'Neill <bronee <at> gmail.com> writes:
>> A big reason why Joda has its own provider is for performance. DateTime
>> does not pre-calculate field values in advance, and so it will apply a
>> time zone offset each time a field value is requested. Joda's time zone
>> provider caches offsets, which is only possible because DateTimeZone has
>> the nextTransition and previousTransition methods. Implementing these
>> methods on top of java.util.TimeZone is nearly impossible.
>>
>> If you decide to simply not implement the next/previous transition
>> methods, you can probably get by, since these methods are not used
>> internally by anything other than the current provider. Be prepared to
>> see a performance impact, however.
>>
>> vijay konnackal wrote:
>> > Now that Sun's tzupdater tool is out, it might be worthwhile to have a
>> > Provider that is driven off the Jdk's timezone data.
>> >
>> > * Don't have to update both Joda and Jdk's for a DST change. When the
>> > deployment is on hundreds of dev and production servers it does make a
>> > difference.
>> > * It will be end of the nasty surprises if Joda and Jdk happen to be
>> > on different versions of Olson data and conversion happen from one to
>> > the other (for third party APIs including various specs) . We have
>> > been bitten by this before.
>> >
>> > Is anybody working on such a solution? If yes, have you faced any
>> > issues with data compatibility.
>> >
>> > Thanks, Vijay
>
> I think vijay raises a valid question. Why can't we have a provider that instead
> of maintaining its own data store, reads it from the JDK timezone data and
> caches it? In this case the cache will not get updated until the server is
> restarted but for most java based products (like ours) we stop the server anyway
> before updating the JDK its running off.
>
> JODA is an excellent API however I am reluctant to use it because then every
> time a customer updates their JDK, we would have to release a patch version just
> to keep the timezone updates in sync.

That sounds like a nice project for a GitHub fork :-)  As said above,
I think its very difficult to do, because information has been lost,
but I welcome anyone that wants to look into it, as it would be a good
option to have.

Stephen

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...