Page 1 of 1

Time-Stamping of Data

Posted: Sat 25 May 2019 15:16
by David Gibson
The TinyTag data files are available in two formats - a raw data format (*.JF) that is read using the TinyTag software, and an export file in standard CSV format. It has been pointed out that there is a time discrepancy between the two. TinyTag says...
There will be a discrepancy between the .jf files and the .csv files at this time of year because the latter always show times in GMT and the .jf files will display data in Tinytag Explorer according to your Windows time/date settings (which will currently be set for BST so they should be an hour ahead of the .csv file data).
We also asked TinyTag about a "time slip", where the sampling interval suddenly seems to jump. They said...
The jumps in the time have been caused by the logger's clocks being synchronised with the system's clock. If you open [a data file] and go to View and Audit, you will see that there are time adjusts there that match up with the data you [are querying].

Re: Time-Stamping of Data

Posted: Thu 30 May 2019 10:02
by Bob Mehew
For clarification, the comment about "go to View and Audit" appears to relate to TinyTag's Explorer software.

I would also add that after a free 6 week use, one then has to pay for the Explorer software. So the csv file downloaded as GMT time stamp seems the easier route to obtain data.

Re: Time-Stamping of Data

Posted: Thu 06 Jun 2019 18:37
by David Gibson
Thanks for that, Bob. It looks as if CSV files are the way to go.

Two fairly technical points...
  • If you are processing the CSV data and you need to create timestamps (e.g. if you are not using Excel to plot graphs, but some other package; and you are giving it Unix timestamps) you should add a time zone to the time string in order to properly characterise it. For example, in PHP, simply add the string " GMT" to the time string before using the strtotime() function on it.
  • Similarly, if you are processing the JF data using PHP's strtotime() function, you should expect it to cope automatically with daylight saving. The reason is that if your PC defaulted to assuming DST when it produced the time string, it will most probably default to using DST when you do the conversion in the opposite direction. Problem solved!
However... although PHP behaves like that, Excel appears not to, (i.e. it does not take DST into account when converting between timestamps and time strings) which means that there is no simple way of recovering from this problem in Excel. I use PHP for data processing and, to be honest, I wouldnt go near Excel with this BCMC data, but that's just a personal preference!