search for: hhmmss

...1:2004(E) allows both the absence of colons in +hh[mm] (basic format) and the presence of colons in +hh:mm (extended format). Again in section 4.2.5.2 where a zone offset is combined with a time of day: if you have hh:mm:ss you are using extended format and the offset MUST have a colon; if you have hhmmss you are using basic format and the offset MUST NOT have a colon. And again in section 4.3.2 (complete representations of date and time of day). If you use hyphens and colons in the date and time part you MUST have a colon in the zone designator. So I am dealing with timestamps in strict ISO 8601...

I have a bunch of files named "[identifier1].[identifier2].[yyyymmdd].[hhmmss].txt" and im having trouble updating my read script for the timestamp. I've been using file.exists and a for loop but its highly inefficient and cumbersome. Would there be someway to create an object containing the string of each .txt file in some directory and to sort them by the date a...

Hi, I'm sure some else has been facing this problem. I want to record all the call coming in my queue. I want this format: YYYYMMDD-HHMMSS-AgentID-CallerId - UniqueID. I'm using the monitor feature inside the queue.conf. I can't use the agents.conf monitor features because I'm using dynamic agent (addqueuemember) The problem I'm facing is that I can change the filename before the call enters the queu...

...ix? # BidsMatrix. Matrix above called ?Bids Matrix? bidrow = 1 # looping through each second for (sec in 1:length(OneSecond$Second) ) { t = as.POSIXlt(onesec$Second[sec],origin = "1970-01-01") sec.onesec = as.numeric(format(t, "%H%M%S")) # convert date/time to format HHMMSS as a number # Find bid for second, which is the last bid before a change in the second for (r in bidrow:length(BidsMatrix$Price)) { # convert the BidsMatrix timestamp to number of format %H%M%S bidTS = unlist(strsplit(as.character(BidsMatrix$Time[r]), split="...

...absence of colons in +hh[mm] (basic format) and the > presence of colons in +hh:mm (extended format). > Again in section 4.2.5.2 where a zone offset is combined > with a time of day: if you have hh:mm:ss you are using > extended format and the offset MUST have a colon; if > you have hhmmss you are using basic format and the > offset MUST NOT have a colon. And again in section > 4.3.2 (complete representations of date and time of day). > If you use hyphens and colons in the date and time part > you MUST have a colon in the zone designator. > > So I am dealing with t...

.... And the last question: is there some sort of filesystem which supports generating 'in-filesystem' snapshots (ie. some sort of copy-on-write block semantics applicable both to files and directories combined with both a root rw directory to access current files and a ro /snapshot/YYMMDD-HHMMSS hierarchy to access snapshots from past dates with the possibility of deleting them at will (ie. generate a snapshot every hour, after 24 hours leave only every 6th one, after 7 days leave only dailies, after a month leave only weeklies etc... - much too complicated, but it's easier to get...

...n +hh[mm] (basic format) and the >> presence of colons in +hh:mm (extended format). >> Again in section 4.2.5.2 where a zone offset is combined >> with a time of day: if you have hh:mm:ss you are using >> extended format and the offset MUST have a colon; if >> you have hhmmss you are using basic format and the >> offset MUST NOT have a colon. And again in section >> 4.3.2 (complete representations of date and time of day). >> If you use hyphens and colons in the date and time part >> you MUST have a colon in the zone designator. >> >&gt...

...mat) and the >>> presence of colons in +hh:mm (extended format). >>> Again in section 4.2.5.2 where a zone offset is combined >>> with a time of day: if you have hh:mm:ss you are using >>> extended format and the offset MUST have a colon; if >>> you have hhmmss you are using basic format and the >>> offset MUST NOT have a colon. And again in section >>> 4.3.2 (complete representations of date and time of day). >>> If you use hyphens and colons in the date and time part >>> you MUST have a colon in the zone designator....

...rity ${CHANNEL} Current channel name ${ENV(VAR)} Environmental variable VAR ${LEN(VAR)} String length of VAR (integer) ${EPOCH} Current unix style epoch ${DATETIME} Current date time in the format: YYYY-MM-DD_HH:MM:SS ${TIMESTAMP} Current date time in the format: YYYYMMDD-HHMMSS ${UNIQUEID} Current call unique identifier ${DNID} Dialed Number Identifier ${RDNIS} Redirected Dial Number ID Service ${HANGUPCAUSE} Asterisk hangup cause ${ACCOUNTCODE} Account code (if specified) ${LANGUAGE} Current language ${SIPDOMAIN} SIP destination domain of an i...

...e of colons in +hh:mm (extended format). Again >>>> in section 4.2.5.2 where a zone offset is combined with >>>> a time of day: if you have hh:mm:ss you are using >>>> extended format and the offset MUST have a colon; if >>>> you have hhmmss you are using basic format and the >>>> offset MUST NOT have a colon. And again in section >>>> 4.3.2 (complete representations of date and time of >>>> day). If you use hyphens and colons in the date and >>>> time part you MUST have...

Hi all, I need to use asterisk to record all phonecall I have test using mixmonitor to record a call. Now I need to set the configure file to let asterisk auto record all calls. I have searched many document but still can not succeed. My version is 1.8beta and I prefer using mixmonitor. Regards!

...; ; This routine is called as a macro before a "Dial" statement, in order ; to record a call into a set of files. It is used hand-in-hand with ; the "macro-record-cleanup" routine. ; I use an AGI to get the base filenames, which are created using the ; date in form YYYYMMDD-HHMMSS which is then added to the ${EXTEN} and ; ${CALLERIDNUM} strings to form the complete filename. ; ; Call this routine with Macro(record-on,${EXTEN},${CALLERIDNUM}) ; ; 2003-06-15 This macro has limited usefulness. Currently, there is ; no synchronization between channels, and the second channel...

I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation

Fix some quoting issues by introducing Unicode quotes. Note this intentionally only affects end-user messages and documentation. Rich.