The date filter on the web GUI is UTC not local. In eastern Australia for example that generally transitions late morning and may be puzzling for a user to only see half their uploads. Simple fix is to label the search feature as “UTC date” although LT/UTC should be an input option.
The sequence thumbnails also have a UTC transition related problem by the most recent (BlackVue video) actually being whatever was captured over that transition first. ie the sort method appears based on MMDDhhmmss rather than YYYYMMDDhhmmss, but more likely to be that part of the tested date stamp comes from the start of sequence and part from the end. May only affect sequences still in server processing. I only notice this while checking upload status.
The sequence thumbnails also have a UTC transition related problem by the most recent (BlackVue video) actually being whatever was captured over that transition first. ie the sort method appears based on MMDDhhmmss rather than YYYYMMDDhhmmss, but more likely to be that part of the tested date stamp comes from the start of sequence and part from the end. May only affect sequences still in server processing. I only notice this while checking upload status.
I think this is because while sequences are processed they are sorted by upload date than by capture date, which is correct. However, like all timestamps, upload timestamps should be in UTC but rendered in the local time zone to the current locale on the page. But, I may be missing something.
@gitne@boris
Well right now my thumbnail list is a mix of both server side BlackVues in processing plus some completed locally processed phone/EXIF ones, but the one BlackVue that transitions 0000Z is at the top one day ahead (but with similar times) as the other’s lower down.
I’d actually prefer the primary sort key to be the processing state, then date. (capture or upload) ie rather than date alone.
Whatever the case I’ll see what happens to the date/time when processing completes. Maybe in future the mapillary tools CLI with have some server side inquiry function that would make this easier. eg a text/csv only dump of own sequences/status that can be sorted and cross-checked with the local upload log.
@boris Processing now complete and the UTC transition thumbnail is still top of the list with the “wrong date” but correct time. ie what would happen if the time comes from the first image in sequence, but the date comes from the last.
Oh and if relevant, the BlackVue ini has been left at UTC-11. The mp4 metadata is all in UTC though.
I also noticed one related thing, @nikola it looks like we show the correct timestamp in the feed, but not in the image details. Here’s a screenshot from Mapillary - I would expect both places to say 9:59 etc.
Great! I am sorry for weaving a bit off topic here but you may also want to consider formatting non‑identifier numbers with toLocaleString() where applicable, e.g. pixel widths, heights, sequence image counts, and the like. Thank you.
Indeed, labeling the search UI with “Date (UTC)” is simple but also rough. I am not sure this really helps anybody because naturally most users operate in their local timezone and thus timestamps in the feed (and now in the “Image details” too) are rendered to the user’s local timezone (which is the right thing to do). All users outside UTC need to do some inconvenient or buggy timezone math. And, if done wrong they are going to expect incorrect results. Imho all of the web app UI should display and expect timestamp inputs in the user’s local timezone. Furthermore, search inputs should not accept the user’s locale date and time formatting but conform to ISO 8601 in the local timezone (because this is the timezone users usually operate in).
@GITNE - when you say “local timezone” you mean the time that I’m in? The feed currently works based on the timezone of where the image is. For example, if I’m located in Europe, but looking at imagery in the US, I don’t expect to see that it was captured in the middle of the night, rather the local time it was captured (e.g. 6 PM). Thoughts?
What I mean by that is the timezone which has been configured in the user’s or system’s profile, e.g. the value of the TZ environment variable, timedated configured timezone (on Unix systems), or the timezone configured in the “Date and Time” control panel (on Windows), etc. In other words, it is the timezone read by the browser from the user or system profile to return off a default Date object by getTimezoneOffset().
Is that so? I am not so sure. However, if indeed then hats off for implementing this.
To be honest, this is exactly what I would expect: Timestamps should be displayed (and searched) relative to my (the viewer’s) timezone rather than the image’s timezone. Sure, you can derive an image’s timezone from its location but you will inevitably run into a lot of nasty corner cases, like incomplete inaccurate changing timezone maps, misplaced images, sequences spanning multiple timezones, introduction or abolition of DST, etc. Imho it is not worth the effort, unless you really need it. It is far easier to configure your browser to run in another timezone should you need to operate in the imagery’s timezone than trying to do it reliably and consistently automatically from the imagery.
Both approaches are valid but deriving timezone data from imagery is fraught with perils. If you like, you can make the timezone selectable in the Mapillary user settings or the viewer per se between the local timezone, the image’s timezone, or an explicit timezone. However, imho this would make things far more complicated than they need to be, not only for users but especially for developers.
Thanks @GITNE - you’ve clearly spent a bunch of time thinking about this, more than I have
The feed and timestamp displayed does currently work on the timezone of where the image is. I think from a user perspective that helps answer questions like “how bright is it in St. Petersburg at 11 PM in July” or “are the street lights on already at 6 PM in October?” or even simpler “what time did I take that image on my vacation in Australia” without having to do too much mental/timezone math.
Your points are well taken, and something for us to consider as well!
Agreed, sorting processing sequences by processing state, then upload timestamp (since processing often seems to happen not chronologically, perhaps even non‑deterministically), and finally processed sequences by capture timestamp sounds very reasonable to me too.
Thank you for the feedback! We are also working on making processing much faster and more reliable (you should see most images showing up very quickly these days as compared to last year). We’re not done, more improvements on the way.
I am sorry for weaving a bit off topic here but you may also want to consider formatting non‑identifier numbers with 
Indeed, labeling the search UI with “Date (UTC)” is simple but also rough. I am not sure this really helps anybody because naturally most users operate in their local timezone and thus timestamps in the feed (and now in the “Image details” too) are rendered to the user’s local timezone (which is the right thing to do). All users outside UTC need to do some inconvenient or buggy timezone math. And, if done wrong they are going to expect incorrect results. Imho all of the web app UI should display and expect timestamp inputs in the user’s local timezone. Furthermore, search inputs should not accept the user’s locale date and time formatting but conform to ISO 8601 in the local timezone (because this is the timezone users usually operate in).
for implementing this.