Time Zone Issue

For engineers Collectors
1

Resurrecting https://groups.google.com/forum/#!searchin/snowplow-user/collector_tstamp/snowplow-user/ebpGcEmWx08/CoPqIXtcbv8J … We’re using the Scala collector. This thread says that the collector timestamp is always the server time, as expected. (And running on EC2, the collector server time is always UTC–verified by calling ‘date’ at the CLI.) But what we’re seeing in atomic.events is that the collector_tstamp is always local to the user, seconds apart from the dvce_created_tstamp. We’re still running r77. Did something change between 02/2014 and r77 that would change the collector_tstamp TZ? Which TZ is correct? Why would collector ever reflect the device locality?

select
      etl_tstamp,
     collector_tstamp,
     dvce_created_tstamp
     from atomic.events 
     where os_timezone = 'America/Los_Angeles'  --'America/New_York', 'UTC', all yield relative local collector_tstamp
     order by collector_tstamp desc
     limit 2000

etl_tstamp                    collector_tstamp              dvce_created_tstamp
2016-06-02 18:14:11.916       2016-06-02 14:31:49.573       2016-06-02 14:31:45.154
2016-06-02 18:14:11.916       2016-06-02 14:31:14.684       2016-06-02 14:31:14.594
2016-06-02 18:14:11.916       2016-06-02 14:31:12.873       2016-06-02 14:31:12.832
2016-06-02 18:14:11.916       2016-06-02 14:31:02.138       2016-06-02 14:31:02.105
2016-06-02 18:14:11.916       2016-06-02 14:31:01.821       2016-06-02 14:31:01.771
2

Hi seanhall,

The dvce_created_tstamp is not actually local - it is UTC. For example, in the JavaScript Tracker, it is generated using new Date().getTime(). The two timestamps are close together because they are both UTC. Does that answer your question?

Regards,
Fred

3

That clears everything up, thank you.