> 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.
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:
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).
https://en.m.wikipedia.org/wiki/ISO_8601