[asterisk-bugs] [Asterisk 0013592]: STRFTIME returns incorrect time

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13592 
====================================================================== 
Reported By:                georgy
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13592
Category:                   Functions/func_strings
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-30 16:44 CDT
Last Modified:              2008-10-01 05:27 CDT
====================================================================== 
Summary:                    STRFTIME returns incorrect time
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
====================================================================== 

---------------------------------------------------------------------- 
 (0093007) davidw (reporter) - 2008-10-01 05:27
 http://bugs.digium.com/view.php?id=13592#c93007 
---------------------------------------------------------------------- 
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 "true" 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.

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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-01 05:27 davidw         Note Added: 0093007                          
======================================================================