Oliver Jowett <oliver@opencloud.com> Thursday 02 December 2010 00:25:35
> Radosław Smogura wrote:
> > Hi,
> >
> > I perform following test:
> > 1. Open connection (GMT+1)
> > 2. Change timezone (GMT+3)
> > 3. Write created timestamp.
> > 4. Change timezone to different connection open and write (GMT+4)
> > 5. Read timezone
> >
> > During this I saw driver sends timestamp encoded with initial (in my case
> > +1), form connection open, time zone. It's because
> > TimestampUtils.toString(Calendar, Timestamp) uses defaultCal. Should it
> > use Calendar.getInstance() or new GregorianCalendar?
> >
> > public synchronized String toString(Calendar cal, Timestamp x) {
> >
> > if (cal == null)
> >
> > cal = defaultCal; // = Calendar.getInstance() // new
> >
> > GregorianCalendar()
>
> There seems to be some confusion about what the bug you are reporting
> actually is.
>
> Is the bug that if you change the JVM's default timezone halfway through
> a run, the change is not reflected in the driver? (i.e. defaultCal is
> initialized once only). Or is it something else?
Yes, problem is when I change default timezone during run.
> I vaguely remember that when writing this code, getting the default
> calendar was quite expensive..
> Oliver
Creating Gregorian Calendar, without fields set in constructir is realy
expensive. To address this we can use {TimeZone, Local} -> GregCal thread
local map, or this what I thinking about is to create new
GC(0,0,0).setTime(....);
--
----------
Radosław Smogura
http://www.softperience.eu