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.
