4

I've been using mktime/localtime for time management, including some heavy arithmetic on dates/times.

I noticed something very weird when providing to mktime a struct tm that contains negative values.

Take the code below. There was a DST change in LA on Nov 3rd, 2013. If I specify time in tm as 2013-11-04 midnight and subtract 24 hours, I get the same value as 2013-11-03 midnight. It is 25 hours difference UTC-wise, which is fine, as with isdst=-1 one could say we're looking at 'wallclock-time'. Same if I subtract 1440 minutes (24*60). But, if I subtract 86400 (24*60*60) seconds, I get 2013-11-03 1am. That is 24 hours difference UTC-wise. Here's the output from the code below:

2013-11-03 00:00:00 (gmtoff=0, isdst=-1) -> 2013-11-03 00:00:00 (gmtoff=-25200, isdst=1) -> 1383462000
2013-12--27 00:00:00 (gmtoff=0, isdst=-1) -> 2013-11-03 00:00:00 (gmtoff=-25200, isdst=1) -> 1383462000
2013-11-04 -24:00:00 (gmtoff=0, isdst=-1) -> 2013-11-03 00:00:00 (gmtoff=-25200, isdst=1) -> 1383462000
2013-11-04 00:-1440:00 (gmtoff=0, isdst=-1) -> 2013-11-03 00:00:00 (gmtoff=-25200, isdst=1) -> 1383462000
2013-11-04 00:00:-86400 (gmtoff=0, isdst=-1) -> 2013-11-03 01:00:00 (gmtoff=-25200, isdst=1) -> 1383465600

For me it doesn't make sense - why are seconds treated differently than minutes, hours and days? I looked at man and the C standard but couldn't find anything.

This behavior breaks some of my assumptions and complicates things. Does someone know a good alternative to mktime/localtime (I tested boost, ICU and tzcode, all too slow for what I need).

Thanks in advance for any thoughts :)

#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 (gmtoff=%ld, isdst=%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)
{
  struct tm tm;
  memset(&tm, 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;
  printf("%s -> ", printtm(tm));
  time_t t = mktime(&tm);
  printf("%s -> %ld\n", printtm(tm), t);
}


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

  test(2013,11,03, 0,0,0, -1);
  test(2013,12,-27, 0,0,0, -1);
  test(2013,11,04, -24,0,0, -1);
  test(2013,11,04, 0,-1440,0, -1);
  test(2013,11,04, 0,0,-86400, -1);

  return 0;
}
Marcin Zukowski
  • 4,281
  • 1
  • 19
  • 28
  • @hobbs: Yes, it does. C11 7.27.2.3, describing the `mktime` function: "The original values of the **`tm_wday`** and **`tm_yday`** components of the structure are ignored, and the original values of the other components are not restricted to the ranges indicated above." (And you just deleted the comment I was replying to.) – Keith Thompson Nov 20 '13 at 19:12
  • Thanks Keith. First of all, I did not delete any comments, no idea what happened. Anyway, I knew about wday/yday, but your answer doesn't clarify why seconds are treated differently here than minutes. – Marcin Zukowski Nov 20 '13 at 20:47
  • Someone named "hobbs" posted a comment, then deleted it as I was writing my reply. I left my reply in place because it still seems relevant. You're right, I didn't clarify why seconds are treated differently -- which is why I posted a comment, not an answer. I might take a closer look later. – Keith Thompson Nov 20 '13 at 21:06

1 Answers1

3

Using mktime with out-of-range values in the struct tm and tm_isdst==-1 is problematic and under-specified. Personally, I think the way your system is behaving here is wrong, but the standard isn't clear on how it's supposed to behave, and thus any such usage is non-portable at best. To do arithmetic on struct tm, you should make sure tm_isdst is set to either 0 or 1 beforehand, so that the result of unambiguous.

Note that one easy way to do this is to simply call mktime on the original struct tm (with tm_isdst==-1) before applying the arithmetic to determine whether daylight time is in effect (i.e. to fill in a definitive value for tm_isdst) then call it again after making your arithmetic adjustments.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Thanks! You're right that isdst=0/1 solves it, and I can use it I think. But I was just very confused by this behavior. – Marcin Zukowski Nov 20 '13 at 20:48
  • 2
    I'm in total agreement that the behavior is confusing and unnatural. But the standard makes no description of how reconciling out-of-range values and determining daylight time status interact with one another, and in fact there's no way that will satisfy everybody's needs, because such broken-down time values are inherently ambiguous. BTW, my guess is that the system you're using just ignores seconds since daylight-time transitions are typically specified in minutes. – R.. GitHub STOP HELPING ICE Nov 20 '13 at 20:55
  • Ah, the best thing about standards is that they are sooo consistent:) Similar thing with mktime is when you specify an ambiguous wallclock time (during the 1-hour autumn overlap) - mktime can return both possible values, depending on its call history. Fun! Thanks for all the replies! :) – Marcin Zukowski Nov 20 '13 at 21:51