Can I make sure I am using the timezone correctly in recordTable

[David Nicholls]

Juergen

In camtrapR::recordTable, if I use timezone = "UTC" the DateTimeOriginal vector displays the same values as the local time on my Reconyx camera image metadata and the timestamp displayed in the header of the image.  This has the advantage of being the same value with no change for the daylight saving period.  And the timezone is the same for every record.

However, it is not really UTC because I am on the other side of the world relative to Greenwich. This is not a satisfactory state of affairs. Sooner or later as I take my analysis beyond camtrapR having my times marked as UTC when they are (in my case) 10 hours offset will cause grief.

If I have this correct, then solutions seem to be: 

create a new column (as a character) with the time relative to a fixed timezone (a non DST zone); or 

convert the DateTimeOriginal to the real UTC time (as a POSIXct with the correct tz specified for the new DateTime vector;  or,  

create a new LocalTime column ensuring that it is local solar time without POSIX being to clever and adjusting the time for the summer or winter time depending on the date.

Have I understood the way recordTable and PIOSIXct are working?

Regards

David

[Juergen Niedballa]

Hi David,

time zones are a bit of a headache indeed.

The main reason for using UTC is that it is a useful default and has no daylight saving time. The big problem with any time zone that has daylight saving time is that your cameras don't know or care about time zones (as far as I know). So either during summer or winter time, your records will be off by 1 hour when you use a time zone with daylight saving time. Even worse, when a record falls into that 1 hour that does not exist (between 2am and 3am when going from winter to summer time in spring), camtrapR might return an error or behave unexpectedly. So if you're lucky and your local time zone does not have DST, go ahead and use it. If it does, better stick to UTC.

The solutions you suggested should work. You could run the functions with UTC (which will give a "wrong" time) and then specify an offset (say + 9 or +10 hours, depending on whether you set up cameras during summer or winter time).

Please also have a look at this thread for a possible solution: https://stackoverflow.com/questions/8004050/import-date-time-at-a-specified-timezone-disregard-daylight-savings-time

Running recordTable with timeZone = "Etc/GMT+10" (or whatever the offset is) seems to be an easier solution.

Please let us know if it works.
Best,
Jürgen

[David Nicholls]

Jürgen

Many thanks thanks for that careful answer.  We are agreed UTC is a correct and the best theoretical answer; it provides a fixed point.   It is just that having the cameras set to UTC is hard on field workers as we try to make sure the dates and times are correct.

I guess the question I am asking; the reassurance I seek is that using timeZone = "Etc/GMT+10" is exactly equivalent to timeZone = "UTC" except that it be always be 10 hours offset. R's POSIXct will treat UTC and "Etc/GMT+10" identically (save for the offset)?  I think the answer is yes.

If POSIXct does not make corrections or changes to my Etc/GMT+10 times then my work with solar time and the diel analysis can be correct. I will not have the 

 discontinuities that summer time - standard time cause.

We have been using (to gain experience) both time zones and picking up the settings on the cameras and making the corrections or adjustments as we find them. I expect to continue with "Etc/GMT+10".  But it is some work to get all the 600 000 plus records across 50 cameras 600 sites, and 1000+ deployments all correct.  

Regards and thanks.

David