• unknown's avatar
    Bug#31800: Date comparison fails with timezone and slashes for greater than comparison · ac3ef6c7
    unknown authored
    BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME
    in comparisons than greater-than and less-than were. ChangeSet makes < >
    comparisons similarly robust with regard to trailing garbage (" GMT-1")
    and "missing" leading zeros. Now all three comparators behave similarly
    in that they throw a warning for "junk" at the end of the data, but then
    proceed anyway if possible. Before < > fell back on a string- (rather than
    date-) comparison when a warning-condition was raised in the string-to-date
    conversion. Now the fallback only happens on actual errors, while warning-
    conditions still result in a warning being to delivered to the client.
    
    
    mysql-test/r/select.result:
      Show that we compare DATE/DATETIME-like strings as date(time)s
      now, rather than as bin-strings.
      Adjust older result as "2005-09-3a" is now correctly seen as
      "2005-09-3" + trailing garbage, rather than as "2005-09-30".
    mysql-test/t/select.test:
      Show that we compare DATE/DATETIME-like strings as date(time)s
      now, rather than as bin-strings.
    sql-common/my_time.c:
      correct/clarify date-related comments, particulary for check_date().
      doxygenize comment while at it.
    sql/item_cmpfunc.cc:
      get_date_from_str() no longer signals an error when all we had
      was a warning-condition -- and one we already gave the user a
      warning for at that. Preamble doxygenized.
    ac3ef6c7
my_time.c 37.6 KB