When using "rotatelogs" with "-l" option and a "%" in filename (triggering calling strftime to get actual file name), the exploded time information passed to strftime is in UTC (because apr_time_exp_gmt() is called?) So using the following line "rotatelogs -l log/%Y-%m-%d 3600" creates log files properly following DST changes but the names of those files follow UTC values. For instance in time zone "Europe/Paris" (GMT+1 with DST) the files end in localtime at 0:59:59 in winter and 1:59:59 in summer: thus starting today (in winter) httpd at 0:30:00 will output 30 minutes in a log named "yesterday" then switch at 1:00:00 to "today's" date. Since using the "-l" option means something like "use localtime not GMT+offset" it would be neat to have the log name in localtime as well. ***** rotatelogs.c 246: 247: apr_time_exp_gmt(&e, tNow); 248: apr_strftime(buf2, &rs, sizeof(buf2), szLogRoot, &e); ***** rotatelogs.new.c 246: 247: if (use_localtime) 248: apr_time_exp_lt(&e, tNow); 249: else 250: apr_time_exp_gmt(&e, tNow); 251: apr_strftime(buf2, &rs, sizeof(buf2), szLogRoot, &e); *****
In the configuration used there "rotatelogs" was running in a chrooted environment and could not access the files for timezone information so it was in fact using GMT time instead of localtime in all date/time related stuff. Adding the proper timezone files to the chrooted environment solved the bug. Still, the documentation improperly states (and led me to think there was a bug) -l Causes the use of local time rather than GMT as the base for the interval or for strftime(3) formatting with size-based rotation. Note that using -l in an environment which changes the GMT offset (such as for BST or DST) can lead to unpredictable results! where I would rather read -l Causes the use of local time rather than GMT as the base for the interval and for strftime(3) formatting. Using -l in an environment which changes the GMT offset (such as for BST or DST) is safe.