Ken Rice added a comment - 03/Jan/12 1:00 PM is this something we really need since you can easily derive the same information the the (u)epoch in your parsing script

Leon de Rooij added a comment - 03/Jan/12 2:16 PM There are always other ways of reaching your goal, but I would definitely like to have the ustamp variant available. If real timestamps in usec resolutions would be in the cdr then I won't have to parse the cdr's before inserting them in the database, other reason is that I like to have all the values in my xml cdrs that I'm "caching" in db columns. I can imagine two reasons for not adding these variables to the cdr's: Redundancy: I agree a bit because there are already the uepoch, epoch and stamp variants. But I'd say it's logical to also have a ustamp since there's also billusec. I don't think most people would want to get rid of billsec because the -usec variant already exists.. At first I wanted to store the uepoch variants in the db but that would always force me to convert them when I'm manually query'ing the db, I wouldn't have an easy overview (I can't translate epoch in my mind yet). CDR size: I agree that they become a bit large, but that can easily be remedied by having a piece of configuration that defines what sections of the cdr will be generated. I'd gladly implement such a thing, for example we could add another section to switch.conf.xml: <configuration name="switch.conf" description="Core Configuration">     <cdr-generation>         <generate name="sec" value="true"/>         <generate name="usec" value="true"/>         <generate name="epoch" value="true"/>         <generate name="uepoch" value="true"/>         <generate name="stamp" value="true"/>         <generate name="ustamp" value="true"/>     </cdr-generation> </configuration> or perhaps they could be configured simply as params: <configuration name="switch.conf" description="Core Configuration">     <settings>         <param name="cdr-generate-sec" value="yes"/>         <param name="cdr-generate-usec" value="yes"/>         <param name="cdr-generate-epoch" value="yes"/>         <param name="cdr-generate-uepoch" value="yes"/>         <param name="cdr-generate-stamp" value="yes"/>         <param name="cdr-generate-ustamp" value="yes"/>     </settings> </configuration> Naming could be better, didn't give that much thought yet, but I would definitely like it if things would work this way.. Then the patch I submitted earlier can be applied now, and by default all timing variants will be generated unless some would be disabled in the configuration. What do you think ?

Leon de Rooij added a comment - 03/Jan/12 2:23 PM I think this syntax would be nice and logical: <configuration name="switch.conf" description="Core Configuration">     <settings>         <param name="cdr-omit-sec" value="false"/>         <param name="cdr-omit-usec" value="false"/>         <param name="cdr-omit-epoch" value="false"/>         <param name="cdr-omit-uepoch" value="false"/>         <param name="cdr-omit-stamp" value="false"/>         <param name="cdr-omit-ustamp" value="false"/>     </settings> </configuration> All values default to false if the params are not specified which would imply that all variants are generated in the cdrs..

Ken Rice added a comment - 03/Jan/12 4:56 PM actually i wonder if we need half of the formats that are in there now for all these stamps when they can all be easily converted from epoch or uepoch... using epoch with postgresql is as easy as SELECT TIMESTAMP WITH TIME ZONE 'epoch' + 1325430081 * INTERVAL '1 second'; if you want to get uepoch in there just divide it by 1000000 to get it to as formated as 1325430081.491133 then SELECT TIMESTAMP WITH TIME ZONE 'epoch' + 1325430081.491133 * INTERVAL '1 second'; this works not just on 9 but older versions also. in this case i have not specified TimeZone so it will default to the TZ of the session as is normal with pgsql. also keep in mind that TZ's on the epochs in FS CDRs are not TZ corrected back to UCT that is something you have to do yourself.

Leon de Rooij added a comment - 04/Jan/12 11:43 AM Ok, thanks for all the tips Ken, really appreciate it, using uepoch and recalculating would definitely work. But otoh, if you want to get rid of all the other formats without breaking anyones current config then making it configurable what formats are stored would be the way to go, or not ?

Ken Rice added a comment - 04/Jan/12 11:56 AM correct this is something we need to look at moving forward. I was just looking at the code for handling the timestamps and was noticing how really its all the same basic uepoch timestamps formatted 50 different ways for the chan vars... My thoughts ended up being do we really need 50 different formats for the various implementations in the core or would it be better if we had a standard format like epoch or uepoch and maybe 1 other human readable format for quick display then everyone else can easily adjust the epoch to whatever format they need in their databases/logging platforms. (seeing how most things do date/time conversion off epoch anyway this shouldnt be a big deal or a resource costly idea while simplifying some code) I'll see if I cant poke a few other people on this and get them to chime in

Ken Rice added a comment - 03/Apr/13 11:53 AM after much thought the only thing we really save there is a little ram/hdd space, do we save anything computationally by doing the checks to see if we want those formats....