[Home]

Summary:ASTERISK-10144: [branch] bug in time-zone with daylight saving time
Reporter:Clod Patry (junky)Labels:
Date Opened:2007-08-22 14:09:49Date Closed:2007-11-07 15:30:15.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20070911__bug10531__localtime_update.diff.txt
Description:apparently, the epoch returned by STRPTIME isnt correct.
Here's a discussion with corydon on IRC.

Even if we specify the tz, the epoch returned isnt correct.

this is due to DST (daylight saving time) in north america.



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

15:11 < JunK-Y>     -- Executing [75@from-sip:2] NoOp("SIP/10-b6a04558", "orig=2007-08-22 19:23:59") in new stack
15:11 < JunK-Y>     -- Executing [75@from-sip:3] Set("SIP/10-b6a04558", "user_expiration=1187828639") in new stack
15:11 < JunK-Y>     -- Executing [75@from-sip:4] SayUnixTime("SIP/10-b6a04558", "1187828639|America/Montreal") in new stack
15:11 < JunK-Y> still 1 extra hour.
15:13 < JunK-Y> even, if i use SayUnixTime("SIP/10-b6a08f60", "1187828639|America/Atlantic"), its the same thing
15:14 <@Corydon76-vcch> Okay, 1 more question... do you ever use any other timezones on your install?
15:14 < JunK-Y> nope, never
15:16 < JunK-Y> Set(user_expiration=${STRPTIME(2007-08-22 19:23:59|America/Montreal|%Y-%m-%d %H:%M:%S)}) this is what ive used.
15:17 <@Corydon76-vcch> JunK-Y: file a bug on this, please
15:17 <@Corydon76-vcch> JunK-Y: specifically, it's inside ast_mktime, but I'm unsure where

Comments:By: Clod Patry (junky) 2007-08-22 14:41:33

-- Executing [75@from-sip:2] NoOp("SIP/10-b6602948", "orig=2007-08-22 19:23:59") in new stack
   -- Executing [75@from-sip:3] Set("SIP/10-b6602948", "user_expiration=1187828639") in new stack
   -- Executing [75@from-sip:4] SayUnixTime("SIP/10-b6602948", "1187828639|America/Montreal") in new stack
[Aug 22 15:54:39] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing A (offset 0) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/day-3' (language 'en')
[Aug 22 15:54:39] DEBUG[31020]: sched.c:204 sched_settime: Request to schedule in the past?!?!
[Aug 22 15:54:39] DEBUG[31020]: sched.c:204 sched_settime: Request to schedule in the past?!?!
[Aug 22 15:54:40] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing B (offset 1) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/mon-7' (language 'en')
[Aug 22 15:54:41] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing d (offset 2) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/20' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/h-2' (language 'en')
[Aug 22 15:54:42] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing Y (offset 3) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/2' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/thousand' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/7' (language 'en')
[Aug 22 15:54:44] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing   (offset 4) in ABdY 'digits/at' IMp
[Aug 22 15:54:44] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing ' (offset 5) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/at' (language 'en')
[Aug 22 15:54:45] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing   (offset 16) in ABdY 'digits/at' IMp
[Aug 22 15:54:45] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing I (offset 17) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/8' (language 'en')
[Aug 22 15:54:46] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing M (offset 18) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/20' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/3' (language 'en')
[Aug 22 15:54:47] DEBUG[31020]: say.c:2996 ast_say_date_with_format_en: Parsing p (offset 19) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/p-m' (language 'en')
By: Tilghman Lesher (tilghman) 2007-08-22 14:45:04

I am unable to reproduce this issue.
By: Clod Patry (junky) 2007-08-22 16:07:12

on another box:
   -- Executing [75@unlimitel-inbound:2] SayUnixTime("SIP/10-b5a93670", "1187828639|America/Montreal") in new stack
   -- <SIP/10-b5a93670> Playing 'digits/day-3' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/20' (language 'fr')
   -- Playing 'multi/A100' (escape_digits=#) (sample_offset 0)
   -- <SIP/10-b5a93670> Playing 'digits/2' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/mon-7' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/2' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/thousand' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/7' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/at' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/8' (language 'fr')
   -- <SIP/64.15.69.138-b5b29c68> Playing 'multi/A124' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/oclock' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/20' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/3' (language 'fr')
   -- <SIP/10-b5a93670> Playing 'digits/p-m' (language 'fr')
 == Auto fallthrough, channel 'SIP/10-b5a93670' status is 'UNKNOWN'
By: Clod Patry (junky) 2007-08-22 16:08:04

The real problem here is:
for the same command, even when specifying the tz, we are getting different results, across all tz.
By: Clod Patry (junky) 2007-08-22 21:00:42

exten => 80,1,SayUnixTime(${STRPTIME(2007-08-22 19:23:59|America/Montreal|%Y-%m-%d %H:%M:%S)});
 
results as:
   -- Executing [80@from-sip:1] SayUnixTime("SIP/10-b6602948", "1187828639") in new stack
[Aug 22 22:13:46] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing A (offset 0) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/day-3' (language 'en')
[Aug 22 22:13:47] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing B (offset 1) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/mon-7' (language 'en')
[Aug 22 22:13:47] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing d (offset 2) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/20' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/h-2' (language 'en')
[Aug 22 22:13:49] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing Y (offset 3) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/2' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/thousand' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/7' (language 'en')
[Aug 22 22:13:51] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing   (offset 4) in ABdY 'digits/at' IMp
[Aug 22 22:13:51] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing ' (offset 5) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/at' (language 'en')
[Aug 22 22:13:52] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing   (offset 16) in ABdY 'digits/at' IMp
[Aug 22 22:13:52] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing I (offset 17) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/8' (language 'en')  <---BAD should be 7!
[Aug 22 22:13:52] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing M (offset 18) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/20' (language 'en')
   -- <SIP/10-b6602948> Playing 'digits/3' (language 'en')
[Aug 22 22:13:54] DEBUG[13840]: say.c:2996 ast_say_date_with_format_en: Parsing p (offset 19) in ABdY 'digits/at' IMp
   -- <SIP/10-b6602948> Playing 'digits/p-m' (language 'en')
 == Auto fallthrough, channel 'SIP/10-b6602948' status is 'UNKNOWN'


which is clearly wrong, since my tz is America/Montreal.
   -- Executing [80@from-sip:1] SayUnixTime("SIP/10-b66029b8", "1187828639|America/Montreal") in new stack  
results as the same way.

To get it correctly (7pm),
i've to use America/Atlantic, which is not my tz.


Even a simple:
exten => 81,1,SayUnixTime(${STRPTIME(2007-08-22 22:23:59||%Y-%m-%d %H:%M:%S)});
gave me 11pm.


By: Clod Patry (junky) 2007-09-11 00:41:05

corydon:
have you been able to reproduce:
exten => 81,1,SayUnixTime(${STRPTIME(2007-08-22 22:23:59||%Y-%m-%d %H:%M:%S)});
gave me 11:23 pm instead of 10:23

??
By: Tilghman Lesher (tilghman) 2007-09-11 10:14:14

No, I get 10:23 pm with that.  Tried it just now.
By: Michiel van Baak (mvanbaak) 2007-09-11 13:09:29

Tried without and with patch on my 1.4 svn systems.
They all tell me 11:23 pm.

Debian etch 4.0 with all updates
asterisk:~# uname -an
Linux asterisk.vanbaak.info 2.6.18-4-xen-686 #1 SMP Thu May 10 03:24:35 UTC 2007 i686 GNU/Linux
asterisk:~# date
Tue Sep 11 20:26:46 CEST 2007
asterisk:~# tzconfig
Your current time zone is set to Europe/Amsterdam
Do you want to change that? [n]: n
Your time zone will not be changed
asterisk:~#
By: Tilghman Lesher (tilghman) 2007-09-11 23:11:19

This (new) patch updates the code to the very latest for the timezone management.
By: Michiel van Baak (mvanbaak) 2007-09-12 02:52:45

Debian etch with latest 1.4 svn and this patch still tells me 11:23 pm
By: Digium Subversion (svnbot) 2007-09-12 14:53:35

Repository: asterisk
Revision: 82285

------------------------------------------------------------------------
r82285 | tilghman | 2007-09-12 14:53:33 -0500 (Wed, 12 Sep 2007) | 4 lines

Working on issue ASTERISK-10144 exposed a rather nasty 64-bit issue on ast_mktime, so we
updated the localtime.c file from source.  Next we'll have to write ast_strptime
to match.

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-09-12 16:07:20

Repository: asterisk
Revision: 82290

------------------------------------------------------------------------
r82290 | tilghman | 2007-09-12 16:07:19 -0500 (Wed, 12 Sep 2007) | 12 lines

Merged revisions 82285 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r82285 | tilghman | 2007-09-12 15:12:06 -0500 (Wed, 12 Sep 2007) | 4 lines

Working on issue ASTERISK-10144 exposed a rather nasty 64-bit issue on ast_mktime, so we
updated the localtime.c file from source.  Next we'll have to write ast_strptime
to match.

........

------------------------------------------------------------------------
By: dea (dea) 2007-10-19 11:34:28

While chasing a similiar issue in new code I was working on, I think
I tracked this down the fact that on my development sever I had a
really old version of tzdata installed.  The old version did not account
for the new US DST rules.
By: Tilghman Lesher (tilghman) 2007-10-23 11:16:24

junky:  can you confirm whether you have the latest tzinfo files?
By: Clod Patry (junky) 2007-10-27 05:59:53

Even with gutsy:
root@rabbit:/etc/asterisk# dpkg --list| grep tz
ii  tzdata                                     2007h-0ubuntu0.7.10            time zone and daylight-saving time data
root@rabbit:/etc/asterisk#

which still result in the regular time and not the saving time.
By: dea (dea) 2007-10-27 12:16:22

Having the correct tzinfo/tzdata package is part of the
solution.  The second part is to have /etc/localtime
point to the correct zone definition.

So installs seem to like to copy the zone file to
/etc/localtime.  I prefer to symlink /etc/localtime
to the correct zone file
By: Jason Parker (jparker) 2007-11-07 15:30:14.000-0600

I'm going to go out on a limb here, and say that DEA is right, and it's just an issue with /etc/localtime not being a symlink.

Reopen if you can verify this isn't the case.