Automatic time zones?

General
10

Ok, apologies for not prefacing this with some description of the problem. Personally, I run into problems when I travel to different time zones and either forget to change my camera’s clock or forget to change my iNat time zone, or both. Usually I have to fix this by using the time offset tool in my photo editor or the extremely clunky batch edit functionality on iNat. Setting the time zone based on coordinates removes one of these sources of error. Yes, it introduces another type of error that @pisum described, but at least the behavior is more consistent and the error is easier to isolate, i.e. if the time looks weird, it’s b/c of the time you provided to iNat, not because of any time zone choice (or lack thereof).

More generally, as @fffffffff indicated (or demonstrated), most people are not aware you can change your time zone on iNat, and we do a terrible job of setting it automatically on sign up:

Top 10 Time Zones By Number of Users (Not Spammer, Not Suspended)

          time_zone          | count  
-----------------------------+--------
                             | 198563
 Eastern Time (US & Canada)  |  21865
 Pacific Time (US & Canada)  |  15846
 Hawaii                      |  14353
 Central Time (US & Canada)  |  12497
 Mexico City                 |   3206
 Mountain Time (US & Canada) |   3089
 Auckland                    |   1872
 American Samoa              |   1458
 Paris                       |   1447

Note that we do not have more Hawaiians than Mexicans. That’s just the top choice in the time zone selector. That’s just users, though. What about actual observations? For the 100,000 most recent verifiable observations, 28,632 ( 28.6%) of them had a time zone offset that didn’t match their coordinates. That means while the time might be right or wrong, the absolute datetime is probably wrong for 29% of those observations. This is a slow calculation to perform, so I can’t get numbers on a more representative sample at the moment, but I really doubt it would be much better.

Also, for what it’s worth

  1. We don’t currently do anything with the offset included in EXIF timestamps. As stated above, this is rarely present. Also, the offset is not the time zone (Pacific Time and Arizona Time are two time zones that have the same offset half of the year), so even if we did use it we would be wrong some of the time. In the Uploader we just the use time zone associated with the user’s account. In the mobile apps, we encode a representation of the datetime observed that includes the time zone when the obs was recorded. If you import a photo, I suspect we use the zone in use at the time of import, which undoubtedly leads to some problems that would also be solved by my proposal.
  2. The time zone reported in the text representations we use in the mobile apps and in Javascript is imperfect. We engage in all sorts of hideous contortions to extract a usable time zone from that text, but since there are a number of different time zones that have the same abbreviations, we can’t do it for the following: AST, BRT, BST, CDT, CST, ECT, GST, IST, PST
  3. Why do we even have time zones in iNat? This was probably a mistake, originally, but at this point I think we need them for bioblitzes and such that span multiple time zones.

I would certainly use the hidden coordinate to determine the time zone in those cases, which yes, could provide more grist for people trying to guess them, but the cost of not using them seems higher. I would not consider large inaccuracies. Using the point alone seems good enough almost all of the time.

I’m not sure I understand this. If I fly from California to New York, forget to update my camera’s clock, take a photo at 5pm EST so the camera registers it as taken at 2pm (PST), and post it to iNat, it will show up as 2pm EST: camera time plus location time zone. I will look at that and think, wait a minute, I didn’t take that at 2pm. Oh crap, I forgot to update my camera. The indication of error is that the time is wrong.

Who’s this Shin-ichi guy?

Indeed, b/c most of the time that three-letter time zone code we can make in the apps at the time of observation suffices. Just not all of the time.

The critique that’s holding the most weight for me so far is the didn’t-change-my-camera-settings AND didn’t-change-my-iNat-time-zone travel argument, mostly b/c you can address that now by batch-editing the time zone. What if we added a time-offset tool to the Uploader? That way you could shift observations forward or backward a few hours before you upload them.

3 Likes