Summary:ASTERISK-16359: [patch] STRFTIME in globals using commas returns incorrect value
Reporter:Warren Selby (wcselby)Labels:
Date Opened:2010-07-13 15:36:14Date Closed:2011-06-07 14:05:23
Versions:Frequency of
Environment:Attachments:( 0) 20100713__issue17637.diff.txt
Description:I'm trying to declare a few date-related global variables to ease my dialplan.  When I declare the following in the [globals] context of extensions.conf, I get unexpected results:


If I evaluate these variables in the dialplan later, using

exten => 7777,n,Verbose(${TIMESTAMP} - ${YEAR} - ${MONTH} - ${DAY})

My output is as follows:

   -- Executing [7777@phones:3] Verbose("SIP/2625-0000d5f0", "Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010") in new stack
Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010 - Tue Jul 13 11:08:42 2010

However, the following line:

exten => 7777,n,Verbose(${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)} - ${STRFTIME(${EPOCH},,%Y)} - ${STRFTIME(${EPOCH},,%m)} - ${STRFTIME(${EPOCH},,%d)})

evaluates with what I expect:

   -- Executing [7777@phones:4] Verbose("SIP/2625-0000d5f0", "20100713-110853 - 2010 - 07 - 13") in new stack
20100713-110853 - 2010 - 07 - 13


I found through the help of the mailing list that if I replace the commas with pipes, the STRFTIME function evaluates the way you would expect it to:


exten => 7777,n,Verbose(${TIMESTAMP} - ${YEAR} - ${MONTH} - ${DAY})

   -- Executing [7777@phones:3] Verbose("SIP/2625-0000e10e", "20100713-135511 - 2010 - 07 - 13") in new stack
20100713-135511 - 2010 - 07 - 13

Now this had the side effect of showing that what I was trying to do wasn't what I will ultimately want, but the fact that pipes work and commas don't still warranted a bug report, as far as I could tell.
Comments:By: Tilghman Lesher (tilghman) 2010-07-13 22:20:49

This patch will fix the problem.  Unfortunately, it creates a completely new problem with backwards compatibility.  Anybody who currently sets global variables and uses a comma as a literal character would find that their dialplan breaks on the version where this patch might appear.  Given our reticence to break existing dialplans, I feel as though we might wish to simply document this behavior more clearly and leave the patch to be applied only by people who definitely want the different behavior.

This is not an issue in 1.6 and forward, because commas are not treated differently in those versions in globals versus dialplan contexts.  So, I'm going to call this a documentation bug and leave it at that.

By: Leif Madsen (lmadsen) 2010-07-14 10:52:59

I agree -- we should simply document this somewhere and "fix" it that way. I'm not entirely sure where we should document this though.

By: Warren Selby (wcselby) 2010-07-14 11:11:41

I'm fine with the proposed "fix".  Perhaps it gets documented in the sample extensions.conf globals context?

By: Leif Madsen (lmadsen) 2010-07-14 13:38:30

Ya, that might be the best location since it'd cover multiple functions.

Anyone want to write up a draft proposal? I can add it to extensions.conf.sample.

By: Paul Belanger (pabelanger) 2010-08-04 11:51:30


By: Paul Belanger (pabelanger) 2010-08-18 07:55:38

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines