[Asterisk-Dev] DATETIME Variable or TIME in general

Thu Oct 9 08:02:39 MST 2003

Interesting point John,   Maybe we need to have a format set in the
asterisk.conf file or some other place to set the format across the entire
system.  We could expose this in the translations through a Set/GetVar to
make it changeable.   We do however need to agree on some default as well so
that if it is not set then there will still be something usable.   It is
also becoming more of a concern to me now that I know for sure that I will
have machines communicating across timezones have to have Logs, CDRs,
Voicemails, Conferences and everything else sorted out.

This is going to be a much bigger change maybe.  You know what format I
want, non-punctuated ISO.  The only addition to this would maybe be
milliseconds for a few cases.  For the most part all those extra colons and
dases or a timezone like CDT or PST is not as useful to me.

-Nicholas Romero

----- Original Message ----- 
From: "John Todd" <jtodd at loligo.com>
To: <asterisk-dev at lists.digium.com>
Sent: Wednesday, October 08, 2003 1:12 PM
Subject: Re: [Asterisk-Dev] DATETIME Variable or TIME in general

> >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
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>