db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4621) Invalid conversion from Timestamp to String when calling setTimestamp() with Calendar
Date Tue, 20 Apr 2010 14:42:50 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-4621:
--------------------------------------

    Attachment: derby-4621.diff

The attached patch adds a regression test case to DateTimeTest and fixes the bug(s) in SQLChar.

The problems were

1) SQLChar.setValue(Timestamp,Calendar) used Timestamp.toString() if the calendar was null,
but had its homegrown code to convert to a string if a calendar was specified. This code did
not add the fraction part if it was zero. I added a special case for that.

2) SQLChar.formatJDBCTime(Calendar,StringBuffer) used Calendar.HOUR (which uses 12-hour clock)
instead of Calendar.HOUR_OF_DAY (which uses 24-hour clock) to get the hour component of Time
and Timestamp values. I corrected that.

Running the regression tests suites now.

> Invalid conversion from Timestamp to String when calling setTimestamp() with Calendar
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-4621
>                 URL: https://issues.apache.org/jira/browse/DERBY-4621
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.3.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: derby-4621.diff, TimestampToVarchar.java
>
>
> If you set a VARCHAR parameter with setTimestamp(), the string will be formatted differently
depending on whether a Calendar is specified or not, even if the default calendar is used.
> Take for example this statement:
>     VALUES CAST(? AS VARCHAR(30))
> I executed this statement twice with the same Timestamp instance. First like this:
>     ps.setTimestamp(1, ts);
> and then like this
>     ps.setTimestamp(1, ts, Calendar.getInstance());
> In this example, both of the methods should use the default Calendar to convert the timestamp
to a string. However, I see that they generate different strings:
> 2010-04-20 15:17:36.0 vs 2010-04-20 03:17:36
> Note there are two differences:
> 1) The method that takes a Calendar object does not show the fraction part (.0)
> 2) The method that takes a Calendar object is 12 hours off (03 instead of 15)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message