5 ms·
> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input. Agreed. However, it might be not so easy
by Archelaos 4y ago
> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.
Agreed. However, it might be not so easy for historical dates, because doing it correctly requires great diligence on the part of the tool developer as well as from the user to choose the correct calendar system. For example:
Q: What is the correct representation of the date of Caesar's death, 15 March 44 BC in ISO-8601?
A: -0043-03-13
Why? -- Ancient dates are typically given according to the Julian calendar excluding a year 0, but ISO-8601 uses a proleptic Gregorian calendar including a year 0.
- nvrspyx 4y agoThis is a good point in a general sense, but I don't think it would be a problem in this particular case for the date some imported OSM data was sourced, which is similar to the "date accessed" for a website in a bibliography.
- Archelaos 4y agoI had the Open Historical Map sub-project in mind, which currently supports only ISO-8601.[1] [1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags#Dates:_Required_for_Rendering https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags...
- netsharc 4y agoIn Java and Javascript, months are 0-based, so October is 9. Geez, imagine forcing people to write "October 15, 2019" as "2019-09-15"
- Archelaos 4y agoYeah, as it already is an imposition to use 10 for what is called "Month Eight" (from Lat.: octo = 8).
- BitwiseFool 4y agoGlad to hear I'm not the only one. A switch flipped in my brain once I realized this and now I routinely mix up October and August. Would it really have been too much to ask that July and August come after December?!
- atoav 4y agoI am one of those guys who use ISO 8601 for everything. It just makes the most sense to me. But I would not force ot onto my users.