Standardize Time Zone Entries

Feature Requests
1

I’ve gone on about my pet peeve of how iNat handles timezones a few times, notably back in Google Groups. However I realize I never did a great job of explaining some of the issues, so I want to revisit this. Right now I’m focused on explaining one particular problem: that there are two distinct time zone formats that iNat uses, and the feature request here is to merge those.

Time zones on iNaturalist can be split into two categories:
Type 1- a format that is entered via text in the same field as the date, such as on the observation upload page, or anywhere else that allows direct editing of the time/date field.
Type 2- a format that is added via a drop-down box, such as on the observation edit screen or on the batch edit form.

Here is an image showing when and where these two types are used:

image
image866×595 104 KB

So, what’s the big deal? Well, I’ll tell you! First of all, only the type 2 timezone field can be fixed through forms like Batch Edit. This means that if you have the type 1 timezone field entered, you cannot use Batch Edit to adjust timezones, because it will only change the type 2 field. This causes a conflict of timezones, as well.

Take for instance this observation. This observation was uploaded in CST (correctly), which was entered in the type 1 field. However, the type 2 field is PST which is what is actually shown on the observation. This was uploaded via the mobile app, and as I learn, the mobile app only enters in type 1, the type 2 is automatically appended by the website based on your profile setting. In short, mobile uploads can never have the correct timezone without some tedious manual editing on the browser later. But note how annoying the type 1 field is to edit and view, since it automatically brings up the date selection box and steals my cursor when I try and look at it. That field is optimized for editing date, and time, not the timezone.

image
image1101×721 250 KB

There is 1 main solution, and 1 temporary solution that I see:

1A. Timezones need to be standardized. Ditch the “type 1” timezone option, and keep timezone as a separate field from the date. The “type 2” timezone field already accomplishes this and allows batch editing to correct it, and it will also pave the way for easier timezone features in future if they come around. Editing type 1 timezones is extremely tedious, and the site fights edits to it since it is optimized for editing date and time only. Timezone should just not be there.

1B. Optional, and a workaround in the mean time: allow batch edit to detect and also edit type 1 timezones. Either by updating them, or just straight up deleting them entirely. As below:

image
image728×874 46.9 KB

2

I agree the current set up is not great. I think our devs would prefer adding time zones automatically, however. (See discussion here if you haven’t already.)

3

That discussion does talk about solutions for incorrect timezones, but the issue of there being “two data fields” for timezones remains. I’m not seeing any particular mention there of this being addressed under that solution.

Largely the issue to keep in mind is that the correct time zone in many observations right now, particularly uploaded from iOS and Apple, is entered in one time zone field and not the other. In other words, a sweeping change that fixes this should keep this in mind so correct time zone data is kept rather than lost.

Still reading through, though. There are some good points over there.

4

I’m closing this as we no longer allow the editing of time zones (or at least, what you enter in that field has no real effect on the observation) and just base them on the observation’s coordinates.