Timestamp and timezone issues in CDR, bug or by design?
When I check the relationship between the epochs and the timestamps, eg answer_epoch vs answer_stamp I realize that after the daylight saving change the epochs are an hour behind. Is this by design? Are the timestamps supposed to be based on the computer's timezone by design, with the epochs based on the UTC value regardless of timezone and daylight savings? select (julianday('2016-03-30 15:23:00')-2440587.5) * 86400.0, -- 1459351379.999998, answer_epoch is 1459347780 (julianday('2016-03-30 14:23:00')-2440587.5) * 86400.0, -- 1459347780.000012, value above - 1hr (julianday('2016-01-27 11:58:53')-2440587.5) * 86400 --1453895933.000001 - prior to daylight savings The first 2 are from the sqlite CDR and the last from the CSV file. -- Frank Church ======================= http://devblog.brahmancreations.com
epoch type timestamps are always UTC by definition, it's a universal/exact format. -- Nathan On 06/19/2016 08:41 PM, vfclists wrote:
When I check the relationship between the epochs and the timestamps, eg answer_epoch vs answer_stamp I realize that after the daylight saving change the epochs are an hour behind. Is this by design? Are the timestamps supposed to be based on the computer's timezone by design, with the epochs based on the UTC value regardless of timezone and daylight savings?
select (julianday('2016-03-30 15:23:00')-2440587.5) * 86400.0, -- 1459351379.999998, answer_epoch is 1459347780 (julianday('2016-03-30 14:23:00')-2440587.5) * 86400.0, -- 1459347780.000012, value above - 1hr (julianday('2016-01-27 11:58:53')-2440587.5) * 86400 --1453895933.000001 - prior to daylight savings
The first 2 are from the sqlite CDR and the last from the CSV file.
-- Frank Church
======================= http://devblog.brahmancreations.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
It is what I was thinking. I just wanted to be sure.
Do service providers generally present the CDRs using UTC time or do they
adjust them to the customers time zone?
On 20 June 2016 at 03:38, Nathan Neulinger <nneul@mst.edu> wrote:
> epoch type timestamps are always UTC by definition, it's a universal/exact
> format.
>
> -- Nathan
>
> On 06/19/2016 08:41 PM, vfclists wrote:
> >
> > When I check the relationship between the epochs and the timestamps, eg
> answer_epoch vs answer_stamp I realize that
> > after the daylight saving change the epochs are an hour behind. Is this
> by design? Are the timestamps supposed to be
> > based on the computer's timezone by design, with the epochs based on the
> UTC value regardless of timezone and daylight
> > savings?
> >
> > select
> > (julianday('2016-03-30 15:23:00')-2440587.5) * 86400.0, --
> 1459351379.999998, answer_epoch is 1459347780
> > (julianday('2016-03-30 14:23:00')-2440587.5) * 86400.0, --
> 1459347780.000012, value above - 1hr
> > (julianday('2016-01-27 11:58:53')-2440587.5) * 86400 --1453895933.000001
> - prior to daylight savings
> >
> > The first 2 are from the sqlite CDR and the last from the CSV file.
> >
> >
> >
> > --
> > Frank Church
> http://devblog.brahmancreations.com
>
This generally depends on the provider. However if you are using a database such as postgresql, you can store time date stamps with a timezone and have your sql extract the tz you want to display. Sent from my iPhone
On Jun 20, 2016, at 6:12 AM, vfclists <vfclists@gmail.com> wrote:
It is what I was thinking. I just wanted to be sure.
Do service providers generally present the CDRs using UTC time or do they adjust them to the customers time zone?
On 20 June 2016 at 03:38, Nathan Neulinger <nneul@mst.edu> wrote: epoch type timestamps are always UTC by definition, it's a universal/exact format.
-- Nathan
On 06/19/2016 08:41 PM, vfclists wrote:
When I check the relationship between the epochs and the timestamps, eg answer_epoch vs answer_stamp I realize that after the daylight saving change the epochs are an hour behind. Is this by design? Are the timestamps supposed to be based on the computer's timezone by design, with the epochs based on the UTC value regardless of timezone and daylight savings?
select (julianday('2016-03-30 15:23:00')-2440587.5) * 86400.0, -- 1459351379.999998, answer_epoch is 1459347780 (julianday('2016-03-30 14:23:00')-2440587.5) * 86400.0, -- 1459347780.000012, value above - 1hr (julianday('2016-01-27 11:58:53')-2440587.5) * 86400 --1453895933.000001 - prior to daylight savings
The first 2 are from the sqlite CDR and the last from the CSV file.
-- Frank Church
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Ken Rice
-
Nathan Neulinger
-
vfclists