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

Mike Matrigali resolved DERBY-3856.
-----------------------------------

         Assignee: Knut Anders Hatlen  (was: Mike Matrigali)
    Fix Version/s: 10.5.3.1
                   10.6.1.1
       Resolution: Fixed

backported to 10.5 and 10.6, resolving as fixed, and reassigning orginal fixer.

> difference between Embedded vs DerbyNetClient in format of return from 
> timestamp(cast(? as varchar(32)))
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3856
>                 URL: https://issues.apache.org/jira/browse/DERBY-3856
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.3.1, 10.4.2.0, 10.5.1.1
>            Reporter: Myrna van Lunteren
>            Assignee: Knut Anders Hatlen
>             Fix For: 10.5.3.1, 10.6.1.1, 10.7.0.0
>
>         Attachments: fix.diff
>
>
> There is a slight difference in how Embedded vs. DerbyNetClient return a 
> specific cast.
> This showed up during conversion of the test lang/datetime.sql which before 
> was only run with Embedded...
> The following sql: 
> prepare dateTimePS as 'values( date(cast(? as integer)),timestamp(cast(? as 
> varchar(32))))';
> execute dateTimePS using 'values(cast(1 as integer), 
> ''2003-03-05-17.05.43.111111'')';
> gives:
>                                1         |2                         
>                                -------------------------------------
> Embedded:         1970-01-01|2003-03-05-17.05.43.111111
> DerbyNetClient:  1970-01-01|2003-03-05 17:05:43.111111
> (in Embedded there's a '-' between date and time part, with DerbyNetClient a 
> space; with Embedded the separator between time elements is ., with 
> DerbyNetClient :. Embedded reflects the data as passed in, with 
> DerbyNetClient it seems to be the default timestamp format).
> I am not sure which is correct at this point, but I confirmed the behavior is 
> like this in latest builds of trunk and 10.3 and 10.4 branches.

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

Reply via email to