# Best way to guarantee times when using BULK load with PHPTIMESERIES? **URL:** \ **Category:** Emoncms\ **Tags:** pulsecount, emoncms\ **Created:** [26 November 2016 13:21 UTC](https://community.openenergymonitor.org/t/best-way-to-guarantee-times-when-using-bulk-load-with-phptimeseries/2320 "2016-11-26T13:21:05Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [26 November 2016 16:12 UTC](https://community.openenergymonitor.org/t/best-way-to-guarantee-times-when-using-bulk-load-with-phptimeseries/2320/2 "2016-11-26T16:12:04Z")
Unfortunately there is no “absolute timestamp” bulk api, I started looking into this a while back as I was seeing some unusual timestamps logged, Firstly as you are using “offset=” the “time=” doesn’t get a look in as the offset option is before the time option in the bulk input [api’s `if else` block](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L93-L114). As far as I could make out the only way you might be able to coerce emoncms to use the supplied timestamp is to use `time=0`, that way the calculated [`$time_ref`](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L107) is zero and there should be no “adjustment” made when each [individual frames timestamp is processed](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L126) further along the code. All the other options “[sentat=](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L95)”, “[offset=](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L101)” or even [legacy mode](https://github.com/emoncms/emoncms/blob/master/Modules/input/input_controller.php#L113) (by omitting an overall timestamp mode) use the timestamp of the server to establish a `$time_ref`, so time difference between the machines and even time in transit could skew the timestamps. So try (reusing your example) http…&data=[…[1480115210,21,21337],[1480115260,21,21337],[1480115270,21,20958],[1480115310,21,20958],[1480115320,21,21146],[1480115360,21,21146]] **&time=0** Also bear in mind that because the input api uses `(int)$itemtime` the timestamp gets truncated to the whole second, not rounded so `1480115210.999` would become 1480115210 not 1480115211. and please let us know how you get on. --- _[View the full topic](https://community.openenergymonitor.org/t/best-way-to-guarantee-times-when-using-bulk-load-with-phptimeseries/2320)._