CentOS 上的 mktime() 中的错误？

Question

我一直在玩 mktime，我注意到一种奇怪且不一致的行为。

我为它提供了一个不在 DST（夏令时）期间的日期，但将 tm_isdst 设置为 1，mktime 通常所做的是将 tm_isdst 更改为 0，并相应地调整时间，偏移 1 小时。

但是，在大约 1928..1933 年的时间段内（找不到不同的范围），行为是不同的。 tm_isdst 字段设置为 0，但时间不变。这会在执行时间计算等时导致奇怪。

我有一个很小的测试程序，它对于给定的输入日期打印：原始结构 tm，在其上调用 mktime 后的结构 tm，mktime 结果和结构 tm，它是在 mktime 结果上调用 localtime 的结果（应该代表与原始时刻相同的时刻）。

输出是：

2013-01-01 12:00:00 (off=0, dst=1) -> 2013-01-01 11:00:00 (off=-28800, dst=0) ->   1357066800 -> 2013-01-01 11:00:00 (off=-28800, dst=0)
1927-01-01 12:00:00 (off=0, dst=1) -> 1927-01-01 11:00:00 (off=-28800, dst=0) ->  -1356930000 -> 1927-01-01 11:00:00 (off=-28800, dst=0)
1929-01-01 12:00:00 (off=0, dst=1) -> 1929-01-01 12:00:00 (off=-28800, dst=0) ->  -1293768000 -> 1929-01-01 12:00:00 (off=-28800, dst=0)
1932-01-01 12:00:00 (off=0, dst=1) -> 1932-01-01 12:00:00 (off=-28800, dst=0) ->  -1199160000 -> 1932-01-01 12:00:00 (off=-28800, dst=0)
1934-01-01 12:00:00 (off=0, dst=1) -> 1934-01-01 11:00:00 (off=-28800, dst=0) ->  -1136005200 -> 1934-01-01 11:00:00 (off=-28800, dst=0)

请注意，对于 2013、1927、1934 年，小时已更改且 dst 设置为 0。但在 1929 年和 1932 年，小时未更改，但 dst 是。

超级奇怪的是，在 tzinfo 中没有关于那个时间范围的信息 - 洛杉矶的 zdump 显示最接近的变化是在 1919 年和 1942 年。

这是在 CentOS 上，内核 2.6.32-358.11.1.el6.x86_64，glibc-2.12-1.107.el6.x86_64。

在 MacOSX 上，进一步调查似乎（始终如一）按预期工作。所以这对我来说看起来像是 mktime() 中的一个错误，但也许我遗漏了一些东西。

测试测试程序如下，也可here

#include <time.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char* printtm(struct tm tm)
{
  static char buf[100];
  sprintf(buf, "%04d-%02d-%02d %02d:%02d:%02d (off=%ld, dst=%d)",
    tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
    tm.tm_hour, tm.tm_min, tm.tm_sec,
    tm.tm_gmtoff, tm.tm_isdst);
  return buf;
}

void test(int y, int m, int d, int hh, int mm, int ss, int isdst)
{
  // Prepare tm structs
  struct tm tm, tm2;
  memset(&tm, 0, sizeof(tm));
  memset(&tm2, 0, sizeof(tm));
  tm.tm_year = y - 1900;
  tm.tm_mon = m - 1;
  tm.tm_mday = d;
  tm.tm_hour = hh;
  tm.tm_min = mm;
  tm.tm_sec = ss;
  tm.tm_isdst = isdst;
  // Convert tm -> t -> tm and print
  printf("%s -> ", printtm(tm));
  time_t t = mktime(&tm);
  printf("%s -> ", printtm(tm));
  printf("%12ld -> ", t);
  localtime_r(&t, &tm2);
  printf("%s\n", printtm(tm));
}

int main()
{
  setenv("TZ", ":America/Los_Angeles", 1);
  tzset();

  test(2013,07,01, 12,0,0, 1);
  test(2013,01,01, 12,0,0, 1);
  test(1927,01,01, 12,0,0, 1);
  test(1929,01,01, 12,0,0, 1);
  test(1932,01,01, 12,0,0, 1);
  test(1934,01,01, 12,0,0, 1);
  return 0;
}

Answer 1

在source to glibc's mktime 你可以找到这个：

/* tm.tm_isdst has the wrong value.  Look for a neighboring
   time with the right value, and use its UTC offset.

   Heuristic: probe the adjacent timestamps in both directions,
   looking for the desired isdst.  This should work for all real
   time zone histories in the tz database.  */

/* Distance between probes when looking for a DST boundary.  In
   tzdata2003a, the shortest period of DST is 601200 seconds
   (e.g., America/Recife starting 2000-10-08 01:00), and the
   shortest period of non-DST surrounded by DST is 694800
   seconds (Africa/Tunis starting 1943-04-17 01:00).  Use the
   minimum of these two values, so we don't miss these short
   periods when probing.  */
int stride = 601200;

/* The longest period of DST in tzdata2003a is 536454000 seconds
   (e.g., America/Jujuy starting 1946-10-01 01:00).  The longest
   period of non-DST is much longer, but it makes no real sense
   to search for more than a year of non-DST, so use the DST
   max.  */
int duration_max = 536454000;

/* Search in both directions, so the maximum distance is half
   the duration; add the stride to avoid off-by-1 problems.  */
int delta_bound = duration_max / 2 + stride;

如果你算一下，你会发现delta_bound 是 268828200 秒，大约等于 8 年半。这几乎是 zdump 日期（1919 年和 1942 年）和你神秘转换的时间（1928 年和 1933 年）之间的差异。每一个都正好关闭 25 小时 30 分钟。我还没有更深入地找到那个幻数的原因。

在不了解整个事情的情况下，我认为该评论基本上意味着当您处于从 1919 年到 1942 年的非 DST 长段的中间部分时，该算法会尝试在其附近找到一个有效的 dst=1 时间戳您提供了错误的 dst=1，并在找到之前放弃，因为 it makes no real sense。中间部分之外的年份也可能没有多大意义，但作为与 Jujuy 相关的调整参数的副作用，表现会有所不同。