gpt4 book ai didi

mysql - STR_TO_DATE 和 ISO8601 原子时间格式

转载 作者:行者123 更新时间:2023-11-29 06:36:39 24 4
gpt4 key购买 nike

我有一个无法更改的 MySQL 数据库,我从中读取日期。问题是我有一个存储日期的 varchar 列。日期以原子时间格式存储,例如。 2014-06-01T00:00:00+02:00

我不知道如何在 STR_TO_DATE 函数中指定格式。我尝试了 STR_TO_DATE(Endtime, '%Y-%m-%dT%H:%i:%s+02:00'),但这不起作用。

有人有解决办法吗?

我正在尝试运行以下查询(无法正常工作):

SELECT *, COUNT(*) as antal 
FROM ivocall_calls
WHERE Agentname LIKE 'Vinh Nguyen'
AND Status1 = 'SALG'
AND STR_TO_DATE(Endtime, '%Y-%m-%dT%H:%i:%s+02:00')
BETWEEN STR_TO_DATE('2014-06-01T00:00:00+02:00', '%Y-%m-%dT%H:%i:%s+02:00')
AND STR_TO_DATE('2014-06-30T00:00:00+02:00', '%Y-%m-%dT%H:%i:%s+02:00')

提前致谢。

最佳答案

这可能是最好的解决方法,使用存储函数解析时间戳并将其从存储格式转换为 MySQL 的 native 格式,使用内置的日期时间数学函数进行时区转换。

下面的函数将正确处理两种格式,YYYY-MM-DDTHH:MM:SSZYYYY-MM-DDTHH:MM:SS+/-HH:MM以及正确形成的 MySQL 日期时间文字,它们将不加修改地传递。

DELIMITER $$

DROP FUNCTION IF EXISTS `from_iso8601_subset` $$
CREATE FUNCTION `from_iso8601_subset`(in_ts TINYTEXT) RETURNS DATETIME
DETERMINISTIC
NO SQL
BEGIN

-- this function takes an input timestamp value in a suppported subset of iso8601 values, and
-- and converts it to the equivalent MySQL datetime value, expressed in the current session's
-- time zone. Since this is also the timezone that columns in the TIMESTAMP data type expect,
-- this causes the input value to be stored correctly in the native TIMESTAMP format, which is.
-- UTC under the hood.

-- if you are taking the value here and stuffing it into a DATETIME column, you need to have your
-- session @@time_zone set to the same zone in which that column should be stored, or use
-- CONVERT(from_iso('input value'),'UTC','Your Desired Time Zone');

-- 2014-02-01T23:59:59Z --

IF (in_ts REGEXP '^[[:digit:]]{4}-[[:digit:]]{2}-[[:digit:]]{2}[T ][[:digit:]]{2}:[[:digit:]]{2}:[[:digit:]]{2}(Z|[+-][[:digit:]]{2}:[[:digit:]]{2})$') THEN

SET in_ts = REPLACE(REPLACE(in_ts, 'T', ' '), 'Z', '+00:00');
RETURN CONVERT_TZ(SUBSTRING(in_ts FROM 1 FOR 19), SUBSTRING(in_ts FROM 20 FOR 24), @@time_zone);

-- unexpected format -- let MySQL's built-in functions do the best they can; this will throw warnings
-- if the input is not a yyyy-mm-dd hh:mm:ss datetime literal; alternately this could return NULL.

ELSE

RETURN CAST(in_ts AS DATETIME);

END IF;

END $$

DELIMITER ;

示例输出:

mysql> SET @@time_zone = 'America/New_York';
Query OK, 0 rows affected (0.08 sec)

mysql> SELECT from_iso8601_subset('2014-06-01T00:00:00+02:00');
+--------------------------------------------------+
| from_iso8601_subset('2014-06-01T00:00:00+02:00') |
+--------------------------------------------------+
| 2014-05-31 18:00:00 |
+--------------------------------------------------+
1 row in set (0.08 sec)

mysql> set @@time_zone = 'UTC';
Query OK, 0 rows affected (0.08 sec)

mysql> SELECT from_iso8601_subset('2014-06-01T00:00:00+02:00');
+--------------------------------------------------+
| from_iso8601_subset('2014-06-01T00:00:00+02:00') |
+--------------------------------------------------+
| 2014-05-31 22:00:00 |
+--------------------------------------------------+
1 row in set (0.08 sec)

我们假设如果输入数据匹配其中一种模式,那么传入的值的内容也将是正常的;如果你给出无意义的输入值,你会得到一些无意义的输出,比如如果你使用的时区为“+99:00”,但它不会失败。该函数不存在任何SQL注入(inject)漏洞。

代码可以进一步优化,但如所写,此函数足够高效,可以在中等功率的机器上每秒计算数千个表达式。

关于mysql - STR_TO_DATE 和 ISO8601 原子时间格式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24209988/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com