I've carefully reasoned my approach, and tested it. I've made a pull request, and I'd be grateful for a careful check of my pull request before it gets merged.
On Friday, 12 August 2016 10:09:52 UTC+2, Steve McLeod wrote: > > I'm using the latest master from GitHub. > > Your question triggered a thought in my mind. In December last year, I > ensured that the CACHED_CALENDAR is cleared each time it is retrieved, to > solve a particularly nasty bug affecting users of my H2-based product when > in the Moscow timezone and using Java 1.8.0_60 (and other Java versions > too). (See > https://github.com/h2database/h2database/commit/96b50c6f4690bf515ddec1b138d6f0136233a836 > > and > https://github.com/h2database/h2database/commit/9932e2d61d8f2af6662120a0ed2420fe2acf4431 > ) > > So it was most likely my fix for that Moscow problem that introduced this > performance problem. > > I think a solution would be to make sure that getTimeLocalWithoutDst uses > its own Calendar object not used by any other method. Then there will be no > need to call Calendar.clear(), meaning that > calendar.get(Calendar.ZONE_OFFSET) should be fast. I'll keep working on > this to see what I can do. > > Regards, > > Steve > > > On Thursday, 11 August 2016 21:37:43 UTC+2, Noel Grandin wrote: >> >> which version are you testing against? Because in recent versions we >> already cache the Calendar object in DateTimeUtils.CACHED_CALENDAR, at >> which point the ZONE_OFFSET should be cheap to calculate. >> > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
