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

I don't like this, for several reasons:

- It's already hard enough to persuade people to use ISO 8601, which is obviously objectively superior to DMY or MDY in several ways. Consistent, widespread support for this uncertainty notation feels like a wild fantasy.

- It mixes logic and data, which IME tends to buy a little terseness at the cost of a lot of mess.

- It's not intuitive. 2015-06?-14 doesn't make it obvious (to me) that the 2015 is uncertain as well as the 06. Imagine the subtle classes of bugs that could arise from manual entry and manipulation of this notation.

- It's not consistent. If 2015-06?-14 says the 2015 and the 06 are uncertain, why doesn't 2015-?06-14 say the 06 and the 14 are uncertain? Moreover, why can the former be expressed with a single ?, but not the latter? Arguably the latter is the more likely scenario (you know something was in 2015 but aren't sure about the month and day).

- It ties uncertainty into the decimal representation. In a month field, "1X" means "October, November or December", but how do we say "September, October or November"?

- Adding uncertainty and approximateness to a data type brings three-valued logic in through the back door. What should 1920-01-XX == 1920-01-XX return? If your environment has a null-like concept, maybe null. Even worse, what about 1920-01-?15 == 1920-01-XX? They're different conceptually (around the 15th vs. any time in Jan), possibly the same date-wise (could both actually be the 13th), different notationally and possibly express exactly the same intention (can easily imagine the same human being switching between these depending on mood). Ugh.



Completely agree with all points.

I wonder if a solution similar to ips and masks would be better. A mask format for dates.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: