[Asterisk-Dev] DATETIME Variable or TIME in general

[John Todd]

>On Tue October 7 2003 20:12, John Todd wrote:
>>  >-----Original Message-----
>>
>>  From: asterisk-dev-admin at lists.digium.com
>>
>>  >[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of John Todd
>>  >Sent: Tuesday, October 07, 2003 1:54 AM
>>  >To: asterisk-dev at lists.digium.com
>>  >Subject: Re: [Asterisk-Dev] DATETIME Variable or TIME in general
>>  >
>>  >  >Which format _should_ be correct? Code or Readme.  Currently I have to
>>  >  >do AGI to fix this would prefer not to have to.  Any objections to
>>  >  >changing to non-punctuated ISO format of:
>>  >>
>>  >>YYYYMMDDTHHMMSSTZD
>>  >>    for today
>>  >>20031006T120234-0500
>>  >>
>>  >>And also adding a Standard Variable of something like ${ISOTIME} for
>>  >>
>>  >  >everyone to use.  Would be very useful for many things including file
>>  >  >names and easy to parse!
>>  >  >
>>  >  >
>>  >  >-Nicholas
>>  >  >
>>  >  >----------
>>  >>
>>  >>Readme Says this:
>>  >>
>>  >>${DATETIME} Current date time in the format: YYYY-MM-DD_HH:MM:SS
>>  >>
>>  >>Code says this:
>>  >>
>>  >>   } else if (c && !strcmp(var, "DATETIME")) {
>>  >>     thistime=time(NULL);
>>  >>     localtime_r(&thistime, &brokentime);
>>  >>     snprintf(workspace, workspacelen -1, "%02d%02d%04d-%02d:%02d:%02d",
>>  >>       brokentime.tm_mday,
>>  >>       brokentime.tm_mon+1,
>>  >>       brokentime.tm_year+1900,
>>  >>       brokentime.tm_hour,
>>  >>       brokentime.tm_min,
>>  >>       brokentime.tm_sec
>>  >>       );
>>  >>     *ret = workspace;
>>  >
>>  >It doesn't seem like a big issue to create an ISOTIME string.  Why
>>  >don't you create the routine and submit it as a feature request to
>>  >the bugtracker (http://bugs.digium.com/)?  I, too, have been using an
>>  >AGI hack to get the time into the "correct" format, since ${DATETIME}
>>  >doesn't have a logical ordering to the values.
>>  >
>>  >JT
>>
>>  At 8:40 AM -0500 10/7/03, Ben Miller wrote:
>>  >Yeah, I'm the victim that put the time in that fashion and probably
>>  >messed up the docs too.  However, Unless ISOTIME is going to fix it for
>>  >everyone, you might consider an app_time(VARIABLE,format) so that you
>>  >and others can change their minds and put the time in whatever format
>>  >they want.
>>  >Just a thought, cause I can vouch for the adage that you can't please
>>  >everyone. ;-)
>>  >Ben
>>
>>  Ben -
>>     Maybe you could create the app_time application, or perhaps as a
>>  different way of doing it there might be a separate variable
>>  (DATEFORMAT) which would take a subset of strftime(3) values, like
>>  this:
>>
>>  exten 1234,1,SetVar(DATEFORMAT="%a, %d %b %Y %H:%M:%S %z")
>>
>>  would then make any call for the value ${DATETIME} look like this:
>>
>>  Tue, 07 Oct 2003 10:09:33 -0500
>>
>>  Of course, you just as easily could change the ${DATEFORMAT} format
>>  to make ${DATETIME} look like:
>>
>>  20031007T100933-0500
>>
>>  This seems a bit more flexible than setting a variable with an
>  > application, which seems like it would clutter a dialplan very
>  > quickly, since every instance where one used ${DATETIME} one would
>  > need to either call a macro or have an additional line in the
>>  dialplan.  I'm more in favor of setting the format once, and then
>>  expecting that format unless told otherwise.
>
>As far as I am concerned YYYY-MM-DD HH:MM:SS.MSEC+TZ is the format ALL times
>should be in unless specifically requested otherwise by a user. This leaves
>no ambiguity as to which timezone the record is from and no mistake as to
>which field is month and day.
>
>After dealing with many broken and stupid time formats in different voice apps
>and VoIP billing systems (Cough..Clarent.. Cough) I have to say this is
>something that is very important to get right.
>
>--
>
>Peter Nixon
>http://www.peternixon.net/
>PGP Key: http://www.peternixon.net/public.asc

OK, no problem.

exten => s,1,SetVar(DATEFORMAT="%Y-%m-%d %H:%M:%S.000%z")
exten => s,2,NoOp(${DATETIME})

would result in the theoretical output of something like this:

-- Executing NoOp("SIP/2000-2359", "2003-10-08 18:08:33.000-0500") in new stack

This would work only, of course, if someone makes the DATEFORMAT 
patch and applies it to Asterisk, in my imaginary world.  :-)  I 
don't see a millisecond stamp in strftime(3) at this point... am I 
not looking hard enough?

Now, if you want that to appear in the CDRs, etc. then that's a 
different story.

JT