5 ms·

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 20

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?

dimava 2y ago
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)
- thunfisch 2y ago
  It's using a slash because that's how ISO 8601 defines time intervals. https://en.wikipedia.org/wiki/ISO_8601#Time_intervals https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
  - funnybeam 2y ago
    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)
  - account42 2y ago
    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.
- dustedcodes 2y ago
  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.
  - zamadatix 2y ago
    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 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.
  - raziel2p 2y ago
    Any time I see slashes in dates I do actually have to double-check whether it's DD/MM or MM/DD.
  - keybored 2y ago
    > 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.
- keybored 2y ago
  Hyphens.
ramses0 2y ago
Better: 2025-01-01..2025-01-31: (eg: git-log-ish format)
account42 2y ago
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.

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?

dimava 2y ago

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)

thunfisch 2y ago
It's using a slash because that's how ISO 8601 defines time intervals. https://en.wikipedia.org/wiki/ISO_8601#Time_intervals https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
- funnybeam 2y ago
  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)
- account42 2y ago
  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.
dustedcodes 2y ago
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.
- zamadatix 2y ago
  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 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.
- raziel2p 2y ago
  Any time I see slashes in dates I do actually have to double-check whether it's DD/MM or MM/DD.
- keybored 2y ago
  > 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.
keybored 2y ago
Hyphens.

ramses0 2y ago

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

account42 2y ago

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.