Sergei, Thank you for your time and responses.
On Tue, Feb 14, 2017 at 3:11 PM Sergei Golubchik <s...@mariadb.org> 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 secur...@mariadb.org Thank you, Seth Shelnutt
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp