Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-191

Rework calendar handling for time-based cols

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      This change makes is so that ResultSet#getDate(int) (and getTimestamp and getTime) is called on an underlying JDBC connection if no custom calendar is available, instead of calling ResultSet#getDate(int, Calendar) with a null Calendar (the latter causes NPEs in Phoenix, and possibly other JDBC drivers).

      In order to get this working, I had to make a number of changes to the OptiqAssert framework as well to allow supplying a custom Calendar. It seems that the HSQLDB ResultSet performs quite differently if you use getTimestamp(int) compared to getTimestamp(int, null). It seems like it would be more ideal to not make the changes to OptiqAssert, but I wasn't able to find a way around it (I'm assuming that this is a bug in HSQLDB).

      ---------------- Imported from GitHub ----------------
      Url: https://github.com/julianhyde/optiq/pull/191
      Created by: gabrielreid
      Labels:
      Created at: Tue Mar 18 15:59:48 CET 2014
      State: closed

        Activity

        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Mar 18 16:49:08 CET 2014, Author: julianhyde]

        Let me know when you've fixed the error on travis.

        Show
        github-import GitHub Import added a comment - [Date: Tue Mar 18 16:49:08 CET 2014, Author: julianhyde ] Let me know when you've fixed the error on travis.
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Mar 18 17:45:25 CET 2014, Author: gabrielreid]

        Sorry about the broken build – it seems to be fixed now, although I had to remove one of the tests that I had added. FWIW, the full test run (i.e. "mvn clean install") works for me locally, so I'm wondering if this also has something to do with timezones somehow.

        The test in JdbcTest that I had to remove was the following:

        /** Tests accessing a column in a JDBC source whose type is DATE. */
        @Test
        public void testGetDate() throws Exception

        { OptiqAssert.that() .with(OptiqAssert.Config.JDBC_FOODMART) .query("select min(\"date\") mindate from \"foodmart\".\"currency\"") .returns("MINDATE=1996-12-31\n"); }
        Show
        github-import GitHub Import added a comment - [Date: Tue Mar 18 17:45:25 CET 2014, Author: gabrielreid ] Sorry about the broken build – it seems to be fixed now, although I had to remove one of the tests that I had added. FWIW, the full test run (i.e. "mvn clean install") works for me locally, so I'm wondering if this also has something to do with timezones somehow. The test in JdbcTest that I had to remove was the following: /** Tests accessing a column in a JDBC source whose type is DATE. */ @Test public void testGetDate() throws Exception { OptiqAssert.that() .with(OptiqAssert.Config.JDBC_FOODMART) .query("select min(\"date\") mindate from \"foodmart\".\"currency\"") .returns("MINDATE=1996-12-31\n"); }
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Mar 18 19:27:47 CET 2014, Author: julianhyde]

        Yup, you're east of Greenwich and Travis is west.

        It's simply not safe to retrieve datetime values in tests and have `OptiqAssert` call `toString()` on them. `java.util.Date.toString()`'s behavior is locale-dependent.

        I think you need to add that test back and figure out a way for it to produce the same result in all locales. Probably you should avoid calling `Date.toString()` in tests. You can call `Date.getTime()` (which returns the millis – the same for all locales) and you can convert datetime values to strings within SQL (SQL does not use locale).

        Show
        github-import GitHub Import added a comment - [Date: Tue Mar 18 19:27:47 CET 2014, Author: julianhyde ] Yup, you're east of Greenwich and Travis is west. It's simply not safe to retrieve datetime values in tests and have `OptiqAssert` call `toString()` on them. `java.util.Date.toString()`'s behavior is locale-dependent. I think you need to add that test back and figure out a way for it to produce the same result in all locales. Probably you should avoid calling `Date.toString()` in tests. You can call `Date.getTime()` (which returns the millis – the same for all locales) and you can convert datetime values to strings within SQL (SQL does not use locale).
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Mar 18 21:06:37 CET 2014, Author: gabrielreid]

        Digging into this a bit more, it looks to me like this isn't a string formatting and locale issue, but instead an issue with how incoming java.sql.Date values are interpreted.

        A java.sql.Date that comes in from another JDBC driver is converted to an int, representing the number of days since the epoch by dividing it by DateTimeUtil.MILLIS_PER_DAY, in SqlFunctions.toInt. This integer is then later converted back into a java.sql.Date by multiplying it by DateTimeUtil.MILLIS_PER_DAY. It appears that this will only work reliably if the underlying timestamp of the incoming java.sql.Date represents a point at midnight in GMT.

        From what I understand of java.sql.Date values in JDBC, they should always be returned from a JDBC driver ResultSet as a timestamp at midnight on the given date, in the local timezone of the JVM where the JDBC driver is running. If this understanding is true, then the requirement of the timestamp being at a point at midnight in GMT will no longer hold, which can cause the incorrect Date to be created from the number of days value.

        Could you provide some insight on why java.sql.Date values are converted to integer when they come in from a foreign JDBC driver? I'm thinking that if the java.sql.Date was used internally instead of first converting it to an integer (and assuming that it's based on GMT), this problem could be avoided.

        Show
        github-import GitHub Import added a comment - [Date: Tue Mar 18 21:06:37 CET 2014, Author: gabrielreid ] Digging into this a bit more, it looks to me like this isn't a string formatting and locale issue, but instead an issue with how incoming java.sql.Date values are interpreted. A java.sql.Date that comes in from another JDBC driver is converted to an int, representing the number of days since the epoch by dividing it by DateTimeUtil.MILLIS_PER_DAY, in SqlFunctions.toInt. This integer is then later converted back into a java.sql.Date by multiplying it by DateTimeUtil.MILLIS_PER_DAY. It appears that this will only work reliably if the underlying timestamp of the incoming java.sql.Date represents a point at midnight in GMT. From what I understand of java.sql.Date values in JDBC, they should always be returned from a JDBC driver ResultSet as a timestamp at midnight on the given date, in the local timezone of the JVM where the JDBC driver is running. If this understanding is true, then the requirement of the timestamp being at a point at midnight in GMT will no longer hold, which can cause the incorrect Date to be created from the number of days value. Could you provide some insight on why java.sql.Date values are converted to integer when they come in from a foreign JDBC driver? I'm thinking that if the java.sql.Date was used internally instead of first converting it to an integer (and assuming that it's based on GMT), this problem could be avoided.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 22:22:15 CET 2014, Author: julianhyde]

        SQL DATE, TIME and TIMESTAMP values do not have a timezone. I repeat. DATE, TIME and TIMESTAMP values do not have a timezone.

        JDBC is different. As you say, values coming out of JDBC are in terms of the client's timezone (or the timezone of the Calendar object, if specified). JDBC is the membrane around the database. Datetime data is changed as it passes through, just as light is refracted as is passes from water to air.

        Optiq internally represents DATE and TIME values as int and TIMESTAMP values as long to make that abundantly clear. If I have a SQL TIMESTAMP that is internally represented as 0, what should be the result if I CAST it to VARCHAR? Clearly, the result should be '1970-01-01 00:00:00' (note: no GMT or UTC in that string), regardless of the timezone that the server or client is running.

        Using `int` and `long` gets rid of the baggage around java.util.Date and java.sql.

        {Date,Time,Timestamp}

        that we might accidentally use. They are also immutable, and as primitive values they can be manipulated more efficiently.

        These are the principles I have used when developing Optiq's datetime support. There may be bugs in it (but there may be bugs in the databases and drivers that Optiq speaks to also).

        I agree with you that a `java.sql.Date` value returned from `ResultSet.getDate(int)` or `ResultSet.getDate(int, Calendar)` represent midnight in the desired timezone. Furthermore, inside Optiq, date values should be 0 modulo 86400000. If either of those does not hold, we have a bug.

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 22:22:15 CET 2014, Author: julianhyde ] SQL DATE, TIME and TIMESTAMP values do not have a timezone. I repeat. DATE, TIME and TIMESTAMP values do not have a timezone. JDBC is different. As you say, values coming out of JDBC are in terms of the client's timezone (or the timezone of the Calendar object, if specified). JDBC is the membrane around the database. Datetime data is changed as it passes through, just as light is refracted as is passes from water to air. Optiq internally represents DATE and TIME values as int and TIMESTAMP values as long to make that abundantly clear. If I have a SQL TIMESTAMP that is internally represented as 0, what should be the result if I CAST it to VARCHAR? Clearly, the result should be '1970-01-01 00:00:00' (note: no GMT or UTC in that string), regardless of the timezone that the server or client is running. Using `int` and `long` gets rid of the baggage around java.util.Date and java.sql. {Date,Time,Timestamp} that we might accidentally use. They are also immutable, and as primitive values they can be manipulated more efficiently. These are the principles I have used when developing Optiq's datetime support. There may be bugs in it (but there may be bugs in the databases and drivers that Optiq speaks to also). I agree with you that a `java.sql.Date` value returned from `ResultSet.getDate(int)` or `ResultSet.getDate(int, Calendar)` represent midnight in the desired timezone. Furthermore, inside Optiq, date values should be 0 modulo 86400000. If either of those does not hold, we have a bug.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 22:47:08 CET 2014, Author: gabrielreid]

        Thanks for the clarification and additional information.

        From my read of the code, the conversion of an incoming Date object into `int` should then take advantage of the fact that the incoming Date is a point at midnight in the local timezone, and create the `int` based on date components of the timestamp to be a point at midnight in GMT. The reverse conversion would then do the inverse, creating a Date whose timestamp points to a time at midnight in the local timezone (or the timezone of a supplied Calendar).

        Does that sound right to you? If so, I'll try to put that together.

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 22:47:08 CET 2014, Author: gabrielreid ] Thanks for the clarification and additional information. From my read of the code, the conversion of an incoming Date object into `int` should then take advantage of the fact that the incoming Date is a point at midnight in the local timezone, and create the `int` based on date components of the timestamp to be a point at midnight in GMT. The reverse conversion would then do the inverse, creating a Date whose timestamp points to a time at midnight in the local timezone (or the timezone of a supplied Calendar). Does that sound right to you? If so, I'll try to put that together.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 22:50:21 CET 2014, Author: julianhyde]

        Optiq should probably ASK FOR the date in timezone it wants (i.e. UTC) by passing in a Calendar. Then let's see whether the underlying drivers comply with that request and give it a value that is 0 modulo 86,400,000.

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 22:50:21 CET 2014, Author: julianhyde ] Optiq should probably ASK FOR the date in timezone it wants (i.e. UTC) by passing in a Calendar. Then let's see whether the underlying drivers comply with that request and give it a value that is 0 modulo 86,400,000.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 23:19:34 CET 2014, Author: gabrielreid]

        Are you sure that adjusting the time value to be based on another time zone is the intended behaviour when a Calendar is passed in to ResultSet#getDate. Looking at the javadoc for ResultSet#getDate(int, Calendar), it says:

        > This method uses the given calendar to construct an appropriate millisecond value
        > for the date if the underlying database does not store timezone information.

        My interpretation of that statement is that the Calendar is only used if the database doesn't know how to interpret the value on its own in order to convert it to a Date (probably if the underlying database type is not a SQL DATE). Although that doesn't sound like a terribly logical use case to me, it is what the javadoc seems to be saying.

        That being said, I'm confident that you know a lot more about this than I do – I just wanted to point that bit from the javadoc out because I find it terribly confusing and it makes me feel like we could be going in the wrong direction if we make the assumption that we can get dates back that point to midnight in a non-local timezone.

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 23:19:34 CET 2014, Author: gabrielreid ] Are you sure that adjusting the time value to be based on another time zone is the intended behaviour when a Calendar is passed in to ResultSet#getDate. Looking at the javadoc for ResultSet#getDate(int, Calendar), it says: > This method uses the given calendar to construct an appropriate millisecond value > for the date if the underlying database does not store timezone information. My interpretation of that statement is that the Calendar is only used if the database doesn't know how to interpret the value on its own in order to convert it to a Date (probably if the underlying database type is not a SQL DATE). Although that doesn't sound like a terribly logical use case to me, it is what the javadoc seems to be saying. That being said, I'm confident that you know a lot more about this than I do – I just wanted to point that bit from the javadoc out because I find it terribly confusing and it makes me feel like we could be going in the wrong direction if we make the assumption that we can get dates back that point to midnight in a non-local timezone.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 23:31:11 CET 2014, Author: julianhyde]

        If the type is a DATE, and the database implements the SQL standard correctly, then the database does not store timezone information.

        You say "other" time zone. There is no other time zone. According to the SQL standard, as I said before, dates in the DB have no time zone.

        The JDBC spec and SQL spec are at serious odds on this issue. (When I store a timestamp object in the database, why the heck does JDBC think I want to convert it to another time zone, and convert it back when I read it back? But that's what the JDBC spec says.)

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 23:31:11 CET 2014, Author: julianhyde ] If the type is a DATE, and the database implements the SQL standard correctly, then the database does not store timezone information. You say "other" time zone. There is no other time zone. According to the SQL standard, as I said before, dates in the DB have no time zone. The JDBC spec and SQL spec are at serious odds on this issue. (When I store a timestamp object in the database, why the heck does JDBC think I want to convert it to another time zone, and convert it back when I read it back? But that's what the JDBC spec says.)
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Mar 19 23:44:08 CET 2014, Author: gabrielreid]

        Ok, that makes sense (in so far as JDBC and dates can make sense). I'll update the patch to use a Calendar in GMT and see how that works out.

        > On 19 Mar 2014, at 23:31, Julian Hyde <notifications@github.com> wrote:
        >
        > If the type is a DATE, and the database implements the SQL standard correctly, then the database does not store timezone information.
        >
        > You say "other" time zone. There is no other time zone. According to the SQL standard, as I said before, dates in the DB have no time zone.
        >
        > The JDBC spec and SQL spec are at serious odds on this issue. (When I store a timestamp object in the database, why the heck does JDBC think I want to convert it to another time zone, and convert it back when I read it back? But that's what the JDBC spec says.)
        >
        > —
        > Reply to this email directly or view it on GitHub.

        Show
        github-import GitHub Import added a comment - [Date: Wed Mar 19 23:44:08 CET 2014, Author: gabrielreid ] Ok, that makes sense (in so far as JDBC and dates can make sense). I'll update the patch to use a Calendar in GMT and see how that works out. > On 19 Mar 2014, at 23:31, Julian Hyde <notifications@github.com> wrote: > > If the type is a DATE, and the database implements the SQL standard correctly, then the database does not store timezone information. > > You say "other" time zone. There is no other time zone. According to the SQL standard, as I said before, dates in the DB have no time zone. > > The JDBC spec and SQL spec are at serious odds on this issue. (When I store a timestamp object in the database, why the heck does JDBC think I want to convert it to another time zone, and convert it back when I read it back? But that's what the JDBC spec says.) > > — > Reply to this email directly or view it on GitHub.
        Hide
        github-import GitHub Import added a comment -

        [Date: Sun Mar 23 09:38:14 CET 2014, Author: gabrielreid]

        I’ve been doing some further experimentation with Optiq and HSQLDB to see how to best approach this. What I’ve found is the following:

        • Supplying a Calendar to get(Date|Time|Timestamp) in HSQLDB rotates the underlying long value by the difference between the local timezone and the timezone of the supplied calendar. I believe this is in line with other JDBC implementations as well.
        • Supplying null for the Calendar in the get(Date|Time|Timestamp) in HSQLDB is equivalent to supplying a GMT calendar. However, supplying a null Calendar causes a NPE in some other JDBC drivers (at least Phoenix and Firebird). This NPE was the original reason I started looking at this.

        If we retrieve the Date/Time values from the underlying JDBC connection in GMT (which is currently implicitly done with HSQLDB by passing in a null Calendar), then I think that they need to be rotated to be zeroed out in the local timezone when they are retrieved from the Optiq ResultSet. This would involve rotating them by the difference between GMT and the local timezone at the time of retrieval. Based on what I see in HSQLDB, we should do the same thing for Timestamp as well, although rotating the time in a Timestamp feels wrong to me, so I’d rather stay away from Calendars entirely when dealing with Timestamps.

        Another issue I uncovered is that the Optiq ResultSet#getString method on a Timestamp field currently formats the Timestamp for GMT, not the local timezone. I assume that this is by design — however, it means that the following two calls will return string representations of timestamps that differ by the difference between GMT and the local timezone:

        resultSet.getTimestamp(tsField).toString(); // returns ts string formatted for local timezone
        resultSet.getString(tsField); // returns ts string formatted for GMT

        I would have expected that both of these calls return the same timestamp — possibly formatted differently, but at least showing the same date and time.

        My proposal for how to go further with this is as follows:

        • explicitly request Date and Time values from the underlying JDBC connection with a GMT calendar
        • in Optiq, rotate Date and Time values by the difference between the local timezone and GMT before returning them from a result set in order to zero them out in relation to the current local timezone
        • request Timestamp values from the underlying JDBC connection without a Calendar, and don’t rotate the underlying long value at all in Optiq (it feels to me like involving Calendars with Timestamps is asking for trouble on various JDBC implementations)
        • Use Timestamp#toString to return a Timestamp as a String in resultSet.getString(timestampField), instead of formatting the return value for GMT

        What do you think of this approach? If this sounds good to you, I should be able to get the patch updated pretty quickly, but I’d rather check it off before starting on the implementation of it.

        Show
        github-import GitHub Import added a comment - [Date: Sun Mar 23 09:38:14 CET 2014, Author: gabrielreid ] I’ve been doing some further experimentation with Optiq and HSQLDB to see how to best approach this. What I’ve found is the following: Supplying a Calendar to get(Date|Time|Timestamp) in HSQLDB rotates the underlying long value by the difference between the local timezone and the timezone of the supplied calendar. I believe this is in line with other JDBC implementations as well. Supplying null for the Calendar in the get(Date|Time|Timestamp) in HSQLDB is equivalent to supplying a GMT calendar. However, supplying a null Calendar causes a NPE in some other JDBC drivers (at least Phoenix and Firebird). This NPE was the original reason I started looking at this. If we retrieve the Date/Time values from the underlying JDBC connection in GMT (which is currently implicitly done with HSQLDB by passing in a null Calendar), then I think that they need to be rotated to be zeroed out in the local timezone when they are retrieved from the Optiq ResultSet. This would involve rotating them by the difference between GMT and the local timezone at the time of retrieval. Based on what I see in HSQLDB, we should do the same thing for Timestamp as well, although rotating the time in a Timestamp feels wrong to me, so I’d rather stay away from Calendars entirely when dealing with Timestamps. Another issue I uncovered is that the Optiq ResultSet#getString method on a Timestamp field currently formats the Timestamp for GMT, not the local timezone. I assume that this is by design — however, it means that the following two calls will return string representations of timestamps that differ by the difference between GMT and the local timezone: resultSet.getTimestamp(tsField).toString(); // returns ts string formatted for local timezone resultSet.getString(tsField); // returns ts string formatted for GMT I would have expected that both of these calls return the same timestamp — possibly formatted differently, but at least showing the same date and time. My proposal for how to go further with this is as follows: explicitly request Date and Time values from the underlying JDBC connection with a GMT calendar in Optiq, rotate Date and Time values by the difference between the local timezone and GMT before returning them from a result set in order to zero them out in relation to the current local timezone request Timestamp values from the underlying JDBC connection without a Calendar, and don’t rotate the underlying long value at all in Optiq (it feels to me like involving Calendars with Timestamps is asking for trouble on various JDBC implementations) Use Timestamp#toString to return a Timestamp as a String in resultSet.getString(timestampField), instead of formatting the return value for GMT What do you think of this approach? If this sounds good to you, I should be able to get the patch updated pretty quickly, but I’d rather check it off before starting on the implementation of it.
        Hide
        github-import GitHub Import added a comment -

        [Date: Mon Mar 24 20:33:58 CET 2014, Author: julianhyde]

        > explicitly request Date and Time values from the underlying JDBC connection with a GMT calendar

        I agree.

        > in Optiq, rotate Date and Time values by the difference between the local timezone and GMT before returning them from a result set in order to zero them out in relation to the current local timezone

        I agree.

        > request Timestamp values from the underlying JDBC connection without a Calendar, and don’t rotate the underlying long value at all in Optiq (it feels to me like involving Calendars with Timestamps is asking for trouble on various JDBC implementations)

        I disagree. We should treat Timestamp the same as Time and Date. That means rotate.

        > Use Timestamp#toString to return a Timestamp as a String in resultSet.getString(timestampField), instead of formatting the return value for GMT

        I mildly disagree. The 'principle of least surprise' you are correct. But it's not unreasonable that `ResultSet.getString` should return the same as
        `CAST(... as varchar)` executed inside SQL, which gives the same result for all client timezones, and is what the current implementation does.

        You can implement your proposed behavior if two things hold: (1) it is what other good JDBC drivers do (based on previous findings, HSQLDB seems to be a good JDBC driver); (2) it doesn't cause the the test suite to go haywire.

        Show
        github-import GitHub Import added a comment - [Date: Mon Mar 24 20:33:58 CET 2014, Author: julianhyde ] > explicitly request Date and Time values from the underlying JDBC connection with a GMT calendar I agree. > in Optiq, rotate Date and Time values by the difference between the local timezone and GMT before returning them from a result set in order to zero them out in relation to the current local timezone I agree. > request Timestamp values from the underlying JDBC connection without a Calendar, and don’t rotate the underlying long value at all in Optiq (it feels to me like involving Calendars with Timestamps is asking for trouble on various JDBC implementations) I disagree. We should treat Timestamp the same as Time and Date. That means rotate. > Use Timestamp#toString to return a Timestamp as a String in resultSet.getString(timestampField), instead of formatting the return value for GMT I mildly disagree. The 'principle of least surprise' you are correct. But it's not unreasonable that `ResultSet.getString` should return the same as `CAST(... as varchar)` executed inside SQL, which gives the same result for all client timezones, and is what the current implementation does. You can implement your proposed behavior if two things hold: (1) it is what other good JDBC drivers do (based on previous findings, HSQLDB seems to be a good JDBC driver); (2) it doesn't cause the the test suite to go haywire.
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Mar 25 15:55:40 CET 2014, Author: gabrielreid]

        Ok, sounds good. I'll check this approach off with a few other JDBC drivers (in addition to HSQLDB) and then update this PR with a patch that follows the two conditions you outlined.

        Show
        github-import GitHub Import added a comment - [Date: Tue Mar 25 15:55:40 CET 2014, Author: gabrielreid ] Ok, sounds good. I'll check this approach off with a few other JDBC drivers (in addition to HSQLDB) and then update this PR with a patch that follows the two conditions you outlined.
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Apr 08 00:19:51 CEST 2014, Author: julianhyde]

        @gabrielreid, Do you know when this patch will be ready? Any chance it will be ready this week, in time for optiq-0.6?

        Show
        github-import GitHub Import added a comment - [Date: Tue Apr 08 00:19:51 CEST 2014, Author: julianhyde ] @gabrielreid, Do you know when this patch will be ready? Any chance it will be ready this week, in time for optiq-0.6?
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Apr 08 08:16:14 CEST 2014, Author: gabrielreid]

        Yes, sorry for the delay on this – I plan to have it ready to go this week still.

        Show
        github-import GitHub Import added a comment - [Date: Tue Apr 08 08:16:14 CEST 2014, Author: gabrielreid ] Yes, sorry for the delay on this – I plan to have it ready to go this week still.
        Hide
        github-import GitHub Import added a comment -

        [Date: Wed Apr 09 17:20:57 CEST 2014, Author: gabrielreid]

        Here's the updated patch – as noted in the commit message, the changes are to rotate
        java.sql.(Time,Date,Timestamp) to be zeroed-out in the local timezone when retrieving them as native java.sql.(Time,Date,Timestamp) obejcts.

        ResultSet#getString(int) still returns timestamps formatted for GMT.

        A null Calendar is no longer passed to underlying JDBC connections.

        Show
        github-import GitHub Import added a comment - [Date: Wed Apr 09 17:20:57 CEST 2014, Author: gabrielreid ] Here's the updated patch – as noted in the commit message, the changes are to rotate java.sql.(Time,Date,Timestamp) to be zeroed-out in the local timezone when retrieving them as native java.sql.(Time,Date,Timestamp) obejcts. ResultSet#getString(int) still returns timestamps formatted for GMT. A null Calendar is no longer passed to underlying JDBC connections.

          People

          • Assignee:
            Unassigned
            Reporter:
            github-import GitHub Import
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development