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

Things like Markdown work because they are intuitive, but the date range syntax in Markwhen is anything but intuitive.

Why 2025-01-22 / 2026-10-24?

Why not 2025/01/22 - 2026/10/24?



Because this is ISO 8601 date format, the standard date format that intentionally uses dashes to not confuse 25/01/22, 01/22/25 and 22/01/26 which are the same date in different formats

(that's why it uses dashes for dates, as for why it uses / for interval I have no idea)


It's using a slash because that's how ISO 8601 defines time intervals. https://en.wikipedia.org/wiki/ISO_8601#Time_intervals


Thanks for linking that. I’m a big proponent of using ISO 8601 but had either missed or completely forgotten about it specifying a format for intervals.

Note that ISO also permits a double hyphen as the interval separator which is hugely preferable to me personally and also works with file names (as mentioned in that Wikipedia article)


Doesn't look like IOS 8601 allows spaces though so this is still an ad-hoc syntax.

RFC3339 at least lets you replace the ugly T with a space but also doesn't specify any spaces around "/" for ranges.


I know ISO 8601, but that doesn't answer my question. Let me rephrase this, why was a format intuitive to a machine chosen instead of a format which feels more intuitive to a human?

I think YYYY/MM/DD - YYYY/MM/DD will mean the correct thing to many more people than YYYY-MM-DD / YYYY-MM-DD, which I suspect many will interpret as an OR and not a RANGE.


EDTF has advantages in less ambiguity. At the same time, Markwhen does also support non-EDTF dates too. The docs do a good job of explaining both https://docs.markwhen.com/syntax/dates-and-ranges.html

Personally I think it goes a little over-flexible on support for non-strict formatted dates to the point it becomes difficult to figure out what a given date string is going to result in rather than feeling easier to use. That's probably part of the reason the primary example uses the clearer format.


> intuitive to machines

Because the “humans” messed up so bad that there weren’t many options left for a simple enough standard.

I would prefer ISO 8601 too over some slight variation which is allegedly more intuitive for homo sapiens sapiens. To keep it simple.


Any time I see slashes in dates I do actually have to double-check whether it's DD/MM or MM/DD.


Hyphens.


Better: 2025-01-01..2025-01-31: (eg: git-log-ish format)


I'm with you on / not being a good range separator but using it for the individual dates is much much worse. Please stick to - for YYYY-MM-DD to avoid confusion and keep / restricted to inbred date formats.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: