Year/month/day is superior when reading full dates, because it’s the least ambiguous. If I only need day and month, I’d rather use month’s full or shortened name (like 27 Sep). Ambiguity is the real enemy here, not any particular order
Year-Month-Day is also my go-to for naming files (at least in systems that don’t have file versioning) because it allows Name sort to list things chronologically. Just have every version of the same file have the same name, then append Year-Month-Day to the end.
I work with a lot of bespoke systems that use proprietary files, so file versioning with something like Google Drive or OneDrive goes right out the window. But Year-Month-Day makes it easy to maintain some semblance of organization.
Year/month/day is superior when reading full dates, because it’s the least ambiguous. If I only need day and month, I’d rather use month’s full or shortened name (like 27 Sep). Ambiguity is the real enemy here, not any particular order
ISO 8601 gang unite!
RFC-3339 gang gang
I scanned through this and my takeaway is that it’s just defining a formal grammar for iso 8601. Did I miss anything important?
Kind of. As I understand it, ISO-8601 is also super broad and allows for a bunch of different potential formats and I think durations.
For instance,
2009-W01-1is a valid ISO-8601 date, meaning2008-12-31(!) which is pretty weird.Year-Month-Day is also my go-to for naming files (at least in systems that don’t have file versioning) because it allows Name sort to list things chronologically. Just have every version of the same file have the same name, then append Year-Month-Day to the end.
I work with a lot of bespoke systems that use proprietary files, so file versioning with something like Google Drive or OneDrive goes right out the window. But Year-Month-Day makes it easy to maintain some semblance of organization.