主页 / user-3703

Mei's questions

Martin Hope
Mei
Asked: 2012-04-13 18:30:48 +0800 CST
  • 0

我有一个包含两个 DATETIME 值的数据库，然后我从中生成一些新值：

tdiff = timediff(d1,d2)+0
day1 = truncate(tdiff/60.0/60.0/24.0,0)
day2 = datediff(d1,d2)+0

所有这三个“变量”都是（临时）数据库中的 FLOAT 字段。我预计这一点，day1并且day2差异永远不会超过 1 或 2。但是，有些值似乎会产生一个疯狂的答案 - 它们往往是tdiff. 计算来自的值tdiff表明计算是正确的。

从概念上讲，day2 应该是 DATETIME 值的日期之间的差异，day1 应该是同一时间范围内的 24 小时周期数。

最大的区别在于 timediff 的最大值：使用计算，24 小时周期的数量刚刚超过 97。但是，使用 DATEDIFF 函数显示的时间跨度低至 60 天。这是没有意义的。

当 TIMEDIFF 结果为 26 个 24 小时周期时，也存在很大差异：DATEDIFF 报告为 10 天 - 或者 TIMEDIFF 结果为 30 个 24 小时周期，而 DATEDIFF 报告为 11 天。TIMEDIFF 报告 79 天时也存在差异，但 DATEDIFF 给出 29 天。

以下是示例输出 - 来自 Ruby 脚本（并采用 Ruby 数组格式） - 包含 d1、d2、TIMEDIFF、24 小时周期、DATEDIFF 列：

["2012-04-11 06:15:21", "2012-02-09 22:11:21", "8.38596e+06", "97", "62"]
["2012-04-11 06:15:22", "2012-02-09 22:13:24", "8.38596e+06", "97", "62"]
["2012-04-11 06:15:25", "2012-02-09 22:15:29", "8.38596e+06", "97", "62"]
["2012-04-11 05:47:25", "2012-03-31 05:07:01", "2.64402e+06", "30", "11"]
["2012-04-11 05:47:26", "2012-03-31 05:09:03", "2.64382e+06", "30", "11"]
["2012-04-11 05:47:27", "2012-03-31 05:27:21", "2.64201e+06", "30", "11"]
["2012-04-11 05:48:43", "2012-01-27 16:39:32", "8.38596e+06", "97", "75"]
["2012-04-11 05:49:00", "2012-04-01 19:58:00", "2.2551e+06", "26", "10"]
["2012-04-11 05:49:00", "2012-04-01 20:00:02", "2.25486e+06", "26", "10"]
["2012-04-11 05:49:00", "2012-04-01 20:02:04", "2.25466e+06", "26", "10"]
["2012-04-11 05:49:05", "2012-04-01 20:04:04", "2.2545e+06", "26", "10"]
["2012-04-11 05:49:06", "2012-04-01 20:06:06", "2.2543e+06", "26", "10"]
["2012-04-11 05:49:06", "2012-01-27 17:36:07", "8.38596e+06", "97", "75"]
["2012-04-11 05:49:07", "2012-04-01 20:08:10", "2.25406e+06", "26", "10"]
["2012-04-11 06:15:06", "2012-03-13 12:23:24", "6.89514e+06", "79", "29"]
["2012-04-11 06:15:07", "2012-03-13 12:25:25", "6.89494e+06", "79", "29"]

为什么这些计算如此不同？我假设这是对 TIMEDIFF 缺乏了解，但我错过了什么？

mysql functions
Martin Hope
Mei
Asked: 2012-04-13 12:20:58 +0800 CST
  • 3

我试图了解如何比较 DATETIME 值（表面上插入为 GMT）和 TIMESTAMP 值（在 INSERT 时间自动生成）。

据我了解， DATETIME 设置为它设置的任何值 - 无论服务器或客户端上的时区是什么，报告都会返回相同的值。

在 MySQL 文档中，听起来 TIMESTAMP 值是在当前时区报告的，但存储在 UTC 中。

在这种情况下，应该可以从 TIMESTAMP 值中减去 DATETIME 值（较早的事件），而无需进行大量时区转换 - 因为 DATETIME 是 GMT 而 TIMESTAMP 值是 UTC。然而，准确地做到这一点 - 并理解它 - 被证明是一个问题。

我有需要(DATETIME - TIMESTAMP)在几分钟和几天内完成的情况。如果我们假设该列d是 DATETIME 并且列t是 TIMESTAMP ......到目前为止，我已经尝试过：

  • DATEDIFF(d,t)
  • TIMEDIFF(d,t)
  • UNIX_TIMESTAMP(d) - UNIX_TIMESTAMP(t) - 1800（占夏令时）

我们这里的时区是美国中部时间 - 当前是中部夏令时间 - CST 的 GMT-6 和当前 CDT 的 GMT-5。

看起来 DATEDIFF 将两个值都转换为日期然后比较它们 - 而不是比较值之间的时间并除以每个值的 24 小时数。因此，无论如何，我认为 DATEDIFF 不会直接为我工作。

那么具体的问题是：

  • 您如何将 GMT 中的 DATETIME 与 TIMESTAMP 值进行比较？具体来说，假设 TIMESTAMP 值是最后生成的，则查找两者之间的分钟数。
  • 获得相同两个值之间 24 小时时段差异的最佳方法是什么？我认为它会是 - 使用 A1 作为上述问题的答案 - TRUNCATE(A1 / (24.0 * 60.0))...

更新：尝试使用具有和CONVERT_TZ值的函数。但是，具有此类规范的函数似乎从当前系统时间读取夏令时设置，而不是从数据库字段读取的时间。这意味着当数据应作为 CST 中的日期时，它被读取为 CDT。US/CentralGMTCONVERT_TZ

我一直认为获得一个字段的 UTC 表示必须很简单TIMESTAMP——在我看来，这会简化事情。

更新 2：在我看来，我对CONVERT_TZ. 我正在使用这个功能，它似乎工作：

TIMEDIFF(CONVERT_TZ(t),'US/Central','UTC'),d)

即使在时区更改（从 CST 到 CDT）时，它似乎也可以工作......

mysql datatypes