Uploaded image for project: 'MariaDB Connector/J'
  1. MariaDB Connector/J
  2. CONJ-349

Connector disregards calendar argument for DATETIME parameters.

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 1.3.0
    • None
    • None
    • Windows, MariaDB 10.1

    Description

      MariaDB Connector/J introduced new DATETIME implementation in version 1.3.0 which breaks legacy code even though useLegacyDatetimeCode is set to true. Before, we have used version 1.1.8 in the following manner (simplified):

      Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
      statement.setTimestamp(index, timestamp, calendar);
      

      Thus, we instructed to always use UTC regardless of the server/client TimeZone. After upgrading to the version 1.4.2 the above-mentioned code stopped working even with useLegacyDatetimeCode set to true. This is rather obvious if we take a look at TimestampParameter source code:

      public void writeBinary(PacketOutputStream writeBuffer) {
          if (options.useLegacyDatetimeCode) {
              calendar = Calendar.getInstance();
          }
          calendar.setTimeInMillis(ts.getTime());
          writeBuffer.writeTimestampLength(calendar, ts);
      }
      

      As you can see, this code completely disregards calendar passed to it as a parameter (it saved in the constructor). As I see it, it is a breaking change.

      If I set useLegacyDatetimeCode to false it will use server's time zone, which also is not a behavior we are trying to achieve.

      Attachments

        Activity

          People

            diego dupin Diego Dupin
            HaravyV Vitali Haravy
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.