Basically what the title says. It is a bit odd that the date in the viewer is formatted specifically in the US style “mm/dd/yyyy” as opposed to something more neutral such as “yyyy-mm-dd,” as a default it is fine but there should at least be an option for other date formats, as well as to use a different date system than AD such as the Holocene Calendar, which helps put historical dates into perspective without significantly changing modern dates.
Assuming you’re referring to the time slider controls in the corner of the homepage, the date format should automatically match the date format from your browser preferences. For example, if you change your browser or operating system locale to British English or Spanish, it’ll switch to dd/mm/yyyy automatically. However, this control doesn’t currently respect your language setting in My Preferences.
Is this consistent with what you’re seeing? If not, can you provide details about your browser environment?
Interesting idea! In general, we also lack support for non-Western calendars, which are important in historical sources for much of the world, but that’s a somewhat harder problem, because relevant technical standards like ISO 8601 don’t address it at all. The Holocene calendar would be easier to implement sitewide: it’s a one-for-one replacement for proleptic Gregorian, so it could be an on-the-fly conversion.
1 Like
Yes, that is consistent with what I am seeing. It is interesting ISO 8601 doesn’t address alternative calendars. I wonder if the information could still be encoded and processed with ISO 8601 but just change how the date is displayed?
Scientific calendars like Holocene would likely be a user preference as opposed to anything baked into the data. After all, units from the International System of Quantities, such as kiloannum, could also be relevant during the same time periods.
On the other hand, cultural calendars like Julian and Chinese could also be implemented as user preferences, but the data would ideally indicate the preferred display date of start_date and end_date, even as it contains raw ISO 8601 dates in proleptic Gregorian. That would allow the data to inform the UI about geographical anomalies in calendar usage, as well as the variation in New Year’s Days:
Some calendars such as Islamic rely on astronomical observations, so converting between calendars becomes more complex and not well suited to automatic conversion before a certain date:
This calendar relies on astronomical observations. Maybe the solution for alternative calendars in OHM lies in linking to Wikidata items rather than introducing new syntax. 
Ah, I see. That does complicate things considerably.