On Wed, Dec 1, 2010 at 6:39 AM, Radosław Smogura
<rsmogura@softperience.eu> wrote:
>
> On Wed, 1 Dec 2010 05:38:41 -0500, Dave Cramer <pg@fastcrypt.com> wrote:
>> On Fri, Nov 26, 2010 at 1:28 PM, Radosław Smogura
>> <rsmogura@softperience.eu> 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()
>>>
>>
>> What do you expect it to do?
>>
>
> I expect proper timestamps encoding store when sending timestamps to
> server. To clarify test case:
> 3. ps.setTimestamp(Timestamp.valueOf("2010-01-01 11:10:12.345"));
> 4. Change timezone to different then connection open TZ and write TZ;
> change to (GMT+4)
> 5. assertTrue(Timestamp.valueOf("2010-01-01 11:10:12.345"),
> rs.getTimestamp(1).toStrig()) - will fail
>
> It's because 3. binds following value "2010-01-01 09:10:12.345000
> +01:00:00", instead of 2010-01-01 11:10:12.345+3, similarly will be for
> read.
>
> My test case shown:
> The result value for #0 is invalid expected:<2010-01-01 11:10:12.345> but
> was:<2010-01-01 12:10:12.345>
I seem to recall that not everyone agrees that this behaviour is desired.
FWIW, timestamps with time zones are pretty useless artifacts since
they are not monotonic, due to to daylight savings time. Further
exacerbating the problem of DST is that it is not the same everywhere.
Some people observe it, some don't.
Dave