[Asterisk-Dev] DATETIME Variable or TIME in general

[Peter Nixon]

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