Based on earlier discussions:
This happens both for times loaded from photo metadata and for times that are input manually on the upload screen. However, you have 2 different ways to input a time manually on the upload screen, and they append the time zones differently.
If I use the pane on the left side of the screen to input the date / time:
… then I end up with a time zone offset (ex. -0500) at the end of my observation date / time:
On the other hand, if I set the time on in the specific observation itself:
… then I end up with an actual time zone (ex. CDT) at the end of my observation date / time:
I think the web uploader should attempt to add an actual time zone in either case. The problem with adding just an offset is that it seems to be either interpreted or translated inconsistently / randomly by the system. For example, observations with a -0500 offset seem to be randomly interpreted or translated to either Eastern (EDT) or Colombia (COT) time (or even something else). The difference in the way different screens display this information is why i use “interpreted or translated” rather than “assigned” in the previous sentences.
Just to illustrate this, below I’m going to include some screenshots of some audio observations that were uploaded via the web. (Dates / times on audio observations must be input manually.) Theoretically, they should all get the same time zone associated with them, but note that they don’t. (Also note that the photo observations with times extracted from the photos all have the proper time zone – CDT – displayed.)
Here is the user Observation screen (where the offsets appear to be interpreted as either -05 or EDT):
Here is the Explore screen (where the offsets appear to be interpreted as either COT or EDT):
