Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nitpick about date formats.

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.

    - to_date('2022-03-27')
    - datetime.strptime("2022-03-27", "%Y-%m-%d")
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).

https://en.m.wikipedia.org/wiki/ISO_8601


kdb and similar systems have had it for years.

https://code.kx.com/q4m3/2_Basic_Data_Types_Atoms/#253-date-...

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.


Dd mm yy would make more sense to me on a physical notepad, since the more relevant info comes first, and you don't have to worry about sorting


To me too, but I'll write yyyy mm dd if it stops Americans writing mm dd yy!

In fairness, they do say it in that order too, so on some level perhaps that really is 'the more relevant' (or natural) to them.


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.


The American way is written how dates are spoken out loud in the states.


Which is why you write, "November 20, 2000", which is easier to read and unambiguous.


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.


I got in the habit years ago of writing dates “27 February 2013” - recommended by some guidelines for lab notebooks as the least ambiguous.


Not that it matters much, since few programming languages will have date and IPv4 literals, but the form you propose does collide with IPv4 notation.

IPv4 addresses in numbers-and-dots notation can contain one, two or three dots.

10.11.12 would mean Nov 12, year 10. Or the IPv4 address you'd perhaps be more tempted to write as 10.11.0.12.

Perhaps we can put the pile of poo emoji to good use?


> 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.


This is why I notate using s-exprs.


Example please? (Non-programmer here; I'm sorta familiar with s-exprs but can't quite picture what you have in mind.)


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.


(joke my-comment)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: