maria-developers team mailing list archive

[Seth Shelnutt <shelnutt2@xxxxxxxxx>]

Sergei,

Thank you for your time and responses.

On Tue, Feb 14, 2017 at 3:11 PM Sergei Golubchik <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 UTC,
>   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 will
> > need to return the timezone from the str_to_datetime function. As
> > mentioned there is no timezone member of the MY_TIME struct. I believe
> > 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.
>
> To support TIMESTAMP WITH TIME ZONE and TIME WITH TIME ZONE literals
> (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
> str_to_datetime.
>
> Regards,
> Sergei
> Chief Architect MariaDB
> and security@xxxxxxxxxxx



Thank you,

Seth Shelnutt