change the format of the date in the JSON to match the format of the date in the file name

[sillypears]

Don't just do that, use an actual date standard instead of some wacky weirdo possible EU-centric one because sorting by dates is an ACTUAL nightmare. DD-MM-YYYY is the least standard thing possible. At the very least do YYYY-MM-DD so it can be sorted easily (year first, month second, day last).

[sillypears]

@Krakenos

[Zamiell]

The format of the date in the filename is already YYYY-MM-DD, so no clue what you are talking about

[sillypears]

This issue is literally about the JSON data inside the files. Not the files. And I am suggesting instead of just making the date on the files be the same as the JSON data, but to actually use some kind of RFC to create proper date objects

https://tools.ietf.org/html/rfc3339

[Zamiell]

glancing at that RFC, it looks like the format it proposes is YYYY-MM-DD, so I still have no clue what you are talking about

[sillypears]

A more common standard is ISO 8601, which I believe is the issue we ran into for Safari having a fit on date conversions that Chrono brought up.

https://en.wikipedia.org/wiki/ISO_8601 -- Here the time can just be 00:00:00 +0000 and you do no timezone conversion.

[Zamiell]

But we don't want to track times, only dates. What exactly is the issue here? Do you think that some code won't be able to properly parse YYYY-MM-DD without us artificially tacking on a bunch of 0's? That seems like a dubious claim.

[sillypears]

You don't have to display the time if you don't want, that's simple. But having an actual date object makes working with them easier vs just using a simple string.

[Zamiell]

Nearly all programming languages will easily be able to parse YYYY-MM-DD. In Go, it is as simple as t.Parse("2006-01-02", str). And doing it that way is actually less complicated than doing t.Parse(time.RFC3339, str).