← Back to team overview

maria-developers team mailing list archive

Re: MDEV-11829 RFC3339 Support


Hello Seth,

I added a comment into the pull request:

Please have a look.


On 02/21/2017 04:37 PM, Seth Shelnutt wrote:

Thank you for your time and responses.

On Tue, Feb 14, 2017 at 3:11 PM Sergei Golubchik <serg@xxxxxxxxxxx
<mailto:serg@xxxxxxxxxxx>> wrote:

    Hi, Seth!

    It's not what SQL standard specifies. It says,

       <...> whenever a datetime value without time zone is to be implicitly
       derived from one with, SQL assumes the value with time zone to be
       adds the time zone displacement to it to give local time, and the
       result, without any time zone displacement, is local.

    This doesn't make much sense to be, really, because it totally ignores
    the session time zone. On the other hand, if you'd convert the UTC value
    to be in the session time zone, you'd totally ignore the displacement
    value. I don't see any behavior being better than the other, so I'd
    stick to the standard by default.

     > In order to convert from RFC3339 timezone to session timezone, we
     > need to return the timezone from the str_to_datetime function. As
     > mentioned there is no timezone member of the MY_TIME struct. I
     > a change to the MY_TIME struct would be the most beneficial and
     > cleanest approach. This would allow for handling RFC3339 and future
     > additions, such as a datetime with time zone field, similar to the
     > ansi timestamp with time zone. The struct is used in a several ways,
     > including packing into longlong, all of those cases would need to be
     > handled. This would be a much larger and more involved patchset.

    (literals only, not expressions or fields or variables), it would be
    enough to parse them in str_to_datetime(), there is no need to return
    the time zone back to the caller in MY_TIME.

In adding a gmt_offset variable, and boolean flag to MY_TIME struct it
will break abi compatibility. What are the standards around abi
compatibility changes? Would adding all relevant changes behind #ifdef
be sufficient? In that case, at compile time a user could choose to
maintain existing abi compatibility, or choose to enable TIME(STAMP)
with TIME ZONE literal support?

     > With any approach, the timezone could then be handled outside of
     > my_time.c, where we have THD and the timezone class, which can easily
     > handle the conversion.

    There is no need to handle time zone outside of my_time.c if
    all we want is TIMESTAMP WITH TIME ZONE literals with the standard
    conversion behavior. It can be implemented completely inside

    Chief Architect MariaDB
    and security@xxxxxxxxxxx <mailto:security@xxxxxxxxxxx>

Thank you,

Seth Shelnutt

Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp