[Home]

Summary:ASTERISK-12803: STRFTIME returns incorrect time
Reporter:georgy (georgy)Labels:
Date Opened:2008-09-30 16:44:27Date Closed:2011-06-07 14:02:58
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/func_strings
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) timezone.txt
Description:STRFTIME returns incorrect time.

Examples:

NoOp(${STRFTIME(315532800)});
should print: Jan 1 00:00:00 1080
prints: Tue Jan  1 03:59:52 1980

NoOp(${STRFTIME(1199201430)});
should print: Jan 1 15:30:30 2008
prints: Tue Jan  1 19:30:07 2008

NoOp(${STRFTIME(1199929555)});
should print: Oct 1 01:45:55 2008
prints: Wed Oct  1 05:45:32 2008

****** ADDITIONAL INFORMATION ******

func_strings.c: Revision: 87262
Fedora 8: 2.6.24.3-12.fc8
Comments:By: Jason Parker (jparker) 2008-09-30 17:06:36

You need to specify a timezone.

core show function STRFTIME
By: georgy (georgy) 2008-09-30 17:18:00

Seems it works with timezone assigned, however I believe all arguments are ment to be optional including 'timezone' as stated in function syntax: STRFTIME([<epoch>][|[timezone][|format]])

I think there has to be UTC or system timezone assumed when 'timezone' argument is skipped.

Anyway, the function should not be returning incorrect minutes and seconds even without timezone, which is my problem here.


By: Sean Bright (seanbright) 2008-09-30 19:04:45

Could you attach (as files, not in the notes) the output of:

ls -al /etc/localtime

And:

od -c /etc/localtime
By: Sean Bright (seanbright) 2008-09-30 19:43:29

Or even better:

/usr/sbin/zdump /etc/localtime
By: David Woolley (davidw) 2008-10-01 05:27:08

My guess is that you have a mix of a wrong timezone and the use of non-POSIX timezone definition files.

The POSIX definition of time doesn't count leap seconds in the internal form of the time.  This allows it to represent future civil times accurately.

Some people prefer to use the "right" timezone files.  These do count leap seconds and therefore become unreliable for times more than about six months in the future, but give accurate time differences, in seconds, across leap seconds.  Another problem is that you need to update the timezone files frequently (approximately every 18 months, but leap seconds are not entirely regular, so you have to check rather more frequently).

Note that proper Unix file time stamps, in archive files, etc., assume POSIX time, and that NTP will require special handling if you don't use the POSIX definitions.

According to <http://tycho.usno.navy.mil/leapsec.html>, TAI differed from UTC by 33 seconds in 2006, which seems more or less consistent with what you are getting.

I would say that the seconds discrepancy is definitely a configuration (or expected results) problem and the hour problem is very probably a configuration problem.

E.g.
date +\%s; date -u; TZ=posix/America/New_York date; TZ=right/America/New_York date; date
1222860733
Wed Oct  1 11:32:13 UTC 2008
Wed Oct  1 07:32:13 EDT 2008
Wed Oct  1 07:31:51 EDT 2008
Wed Oct  1 12:32:13 BST 2008

md5sum /etc/localtime /usr/share/zoneinfo/{,posix/,right/}{GB,America/New_York}
4c9f9c5c5f86bcc5465c08831ef59e75  /etc/localtime
4c9f9c5c5f86bcc5465c08831ef59e75  /usr/share/zoneinfo/GB
4894d160f97e824d37378342cfe73ff0  /usr/share/zoneinfo/America/New_York
4c9f9c5c5f86bcc5465c08831ef59e75  /usr/share/zoneinfo/posix/GB
4894d160f97e824d37378342cfe73ff0  /usr/share/zoneinfo/posix/America/New_York
5cdb1d2660049971e782b1eea3b15141  /usr/share/zoneinfo/right/GB
de82533f27108cddd3adc6e92300ef47  /usr/share/zoneinfo/right/America/New_York

Note that, the reason that I get 32 seconds, rather than 33, is that the timezone files aren't being actively maintained on that system.  If you use "right" files, you must actively monitor for leap second announcements.


By: georgy (georgy) 2008-10-01 08:52:48

I am in Georgia (Europe) and out timezone has been kind of changed couple of years ago. It is now very complicated whether we are GMT+4 or GMT+3. I think we are a 'special' GMT+3, which is not or partially supported by fedora timezones. I had problem with that and had to set the clock GMT+4, otherwise I am getting incorrect system times.

Attaching file...


By: David Woolley (davidw) 2008-10-01 09:19:53

You need to fetch and compile the timezone files yourself, but that isn't to do with an Asterisk bug, so could you possibly re-raise on the user forum <http://forums.digium.com/viewforum.php?f=1>.  The seconds issue will be the result of using "right", rather than Posix.
By: Sean Bright (seanbright) 2008-10-01 09:59:29

Maybe I am not understanding... by default, asterisk will use /etc/localtime to convert the epoch passed to STRFTIME to the localtime (if a tz is not specified).  The reporter is GMT+4, which is in line with the results he is seeing.  Where exactly is the bug in asterisk?
By: David Woolley (davidw) 2008-10-01 10:09:55

I don't believe there is a bug in Asterisk, which is why I'm trying to redirect him to the forum.
By: Tilghman Lesher (tilghman) 2008-10-01 17:56:34

Reporter redirected to forum.