In general, timezone choices don't affect actual underlying timestamps, they just change how timestamps are represented when displayed on a screen or exported to a file. 

Timestamps are stored internally by computers as milliseconds since UNIX epoch, which is the same regardless of timezone. For example, an internal time of 1532739980512 epoch milliseconds translates to 01:06:20 on July 28, 2018 in the UTC timezone. If I displayed this timestamp in eagle.io with my user timezone preference set to my local timezone (Australian Eastern Standard Time which is UTC +10) it would look like 11:06:20 on July 28, 2018. If another user displayed it with their user timezone preference set to Mountain Time (UTC -7) it would look like 18:06:20 on July 27, 2018, but only if they chose to ignore Daylight Saving. If Daylight Saving were not ignored, then Mountain Time (UTC-7) in the middle of summer is actually Mountain Daylight Time (UTC-6) and the timestamp would look like 19:06:20 on July 27, 2018.  It's all exactly the same time internally; the data actually stored in the database is the 1532739980512 milliseconds number. That number is never changed, it's only displayed in different ways. User timezone preference is configured in the user profile general settings; note that my timezone offset of +10:00 will become +11:00 during the (Australian) summer as I have chosen to not ignore Daylight Saving:

However, while user timezone preference only affects the representation of timestamps, there are other timezone choices which can affect the actual internal time, not just the representation. When we ingest records from Campbell loggers, due to the way that times are represented internally on the device, we need to know what timezone the logger clock is set to in order to correctly translate them to the milliseconds-since-epoch format. And when we ingest records from a text file, and the timestamp does not contain a zone portion, we rely on the timezone configured for that Data Source to translate to the milliseconds-since-epoch format: 

Unfortunately, if you have ingested records which relied on the configured timezone during translation, but that timezone was incorrect, the timestamps for those records will now be incorrect. This can only be fixed by exporting and re-importing the records, and the configured timezone during exporting would need to be offset to allow for the original error. 

Exporting records is just another way of representing them, so when you choose a timezone (in the advanced export options), that timezone will be how the timestamps are represented in the file that gets created:


It's important to note that by default, the export timezone will be your user-preferred timezone, not the timezone configured on the Data Source. If the Data Source timezone is different, and you want the exported records to be displayed with the Data Source timezone, you would have to change the export timezone manually. This is strongly advised if you are planning to re-import the records back to the same Data Source. In the above example, my Data Source was configured with a timezone of Mountain Time, therefore I have configured my export with the same timezone. Now, if I ever need to re-import those exported records back to the same Data Source, I will be importing records that have timestamps represented in Mountain Time back to a Data Source which is expecting timestamps represented in Mountain Time.


A few points to note:

  • UTC and GMT are often used interchangeably. The difference is that GMT is an actual timezone, while UTC is a time standard. They can both be used to represent the zero point from which a timezone offset is calculated. They are also equivalent to the military Zulu timezone.
  • One of the best resources to help with timezone conversions and translations is https://www.timeanddate.com/time/
  • UNIX epoch time is actually defined as number of seconds since the UNIX epoch. However, computer systems (such as eagle.io) that need to store time with more resolution will instead use milliseconds since the UNIX epoch as an internal representation. Conversion to and from UNIX epoch time can be done in most computer languages or with an online tool such as https://www.epochconverter.com/
Did this answer your question?