Assign correct time zone

[annam21]

Feature request - assign the correct time zone when manipulating collar data. If left blank (as current), it tries to assign system time, which is incorrect.

[Huh]

What should the default be? I haven't thought about this in a while, but the system time seems kinda reasonable for most agency work.

[annam21]

No, because it actually comes in as UTC, but the computer tries to assign it as system time, which would make all analyses off by a lot (7 hours for mountain)

I have verified with Telonics that the data are recorded as UTC. I have verified with Vectronic that the acquisitiontime column from the API is UTC.

[Huh]

Depends on which column we pick then, no?

What is your proposal for a default? Could be an error. What about DST? How strictly are they defining UTC?

[annam21]

Since we know how Vectronic is coming in, we could hard-code it. We could also verify how Lotek and ATS come in.

Otherwise, I like the idea of an error. It will make people annoyed, but whenever you're introducing POSIX, I feel strongly that it should be purposefully assigned a time zone.

[Huh]

I don't want to favor any one company. I also remember data structures with multiple time columns, so skeptical of any default being correct. I think I like the error as well.

[Huh]

Can you point me to the function you are commenting on here? Are you going to propose a solution or are you asking someone else to do it?

Thanks

[annam21]

collar::morph_gps

I wanted to make a note so we don't forget. I might be able to propose a solution at a later date.

[ericnewkirk]

Re: confirming time data expectations with manufacturers, this is from ATS in 2017:

E: When we download the data to text from the ATS IDAQ webpage are the dates and times UTC? I assume so since I've never seen an option to change them to anything different, but wanted to make sure.

ATS: That is correct......

And this is from the same guy at ATS in 2019, after someone I worked with realized the times didn't make sense:

Our Iridium system has never delivered final data with strictly GMT timestamps. Data has always been delivered with timestamps per the timezone selection uploaded into the collar (which can include a GMT offset of 0 if the client so chooses).

It's a different company, I know, but my point is just that some of the people providing the data don't even know what's going on. I was using a really similar workflow to the ATS web scraper in this package. Always a moving target...