2013-02-27 is the current standard, but more so as a result of "this is how we've done things" and not "this is the best way to do it". The hyphens make the notation ambiguous with substraction, therefore in programming languages dates are quoted and represented as strings, which in turn get passed to a parsing function.
The obvious alternative is to use an unambigous notation from the list such as dot notation. 2022.03.27 doesn't collide with floating point number notation, nor with ipv4 notation, nor any arithmetic operation and thus can be used to represent dates in programming languages directly - without quotation and without the need to stringly type them.
It's one of those many examples where "best practices" really only mean "current common practices".
> 2013-02-27 is the current standard, but more so as a result of "this is how we've done things" and not "this is the best way to do it".
That may be, but it's also codified as ISO 8601 [1], so that's a strong reason not to use a non-standardized format.
> The hyphens make the notation ambiguous with substraction, therefore in programming languages dates are quoted and represented as strings
If you're hard-coding a date in code, you have other choices. You can use a UNIX timestamp (uint). You can create a Date object directly, eg:
Date Created = new Date(2022, 04, 30);
I don't know of any languages where Date is a primitive type (are there any?) so having a literal notation - which I think is what you're advocating - doesn't really make sense: there has to be an allocation or conversion anyway. This is in contrast to actual primitive types like float, int, char, etc where most languages do have a literal way to express those in source.
If you're reading a date from user configuration, you need to parse at some point anyway. Otherwise, store dates as serialized date objects and in your database as date-type columns (or as UNIX timestamps, if date isn't an available type).
Float is an imprecise transformation from text to a binary fixed size representation. I don't see how floats would be considered a native type while datetime types not.
Having it non-native while the option exists seems to be like a voluntary torture. But it makes sense considering community bubbles surrounding programming languages and not bridging the gaps between them. What can be a 100 lines of Java can be expressed in 20 of Python can be expressed in 5 lines of a data language.
When writing on paper I personally like something like "Saturday 30th of April 2022", or some abbreviation of it, in addition to global context it also adds some weekly context that can be nice when trying to remember when you did something.
And some seasonal context from the month, like 06 doesn't bring many associations to my head, June tells me it was probably hot, and the type of atmosphere and activities going on around at the time.
The units get smaller from let to right, which is what you expect. The American system doing things like month/day/year is unintuitive and causes ambiguity, but if it was done in an intuitive way in the first place (day/month/year), there would be none.
Dots don't allow it not being a full date though, e.g. the month 2022.04 is indistinguishable from the number two thousand and twenty-two point zero four.
> The hyphens make the notation ambiguous with substraction
In Lisp they wouldn’t, and in statically typed languages it probably wouldn’t be a problem either, as the compiler would tell you that you can’t use a date as a number.
On the other hand, the need for date literals in program code is rare enough that it likely doesn’t warrant introducing a dedicated syntactic form.
In Lisp, operators and function calls are all prefix, so this would be subtraction: (- 10 5) I think (it's been awhile lol). A hyphen anywhere else wouldn't be confused with subtraction. This is just a guess though.
2013-02-27 is the current standard, but more so as a result of "this is how we've done things" and not "this is the best way to do it". The hyphens make the notation ambiguous with substraction, therefore in programming languages dates are quoted and represented as strings, which in turn get passed to a parsing function.
The obvious alternative is to use an unambigous notation from the list such as dot notation. 2022.03.27 doesn't collide with floating point number notation, nor with ipv4 notation, nor any arithmetic operation and thus can be used to represent dates in programming languages directly - without quotation and without the need to stringly type them.It's one of those many examples where "best practices" really only mean "current common practices".