@minus I had a coworker ask why I wrote dates like that and not "like a normal person" the other day... I didn't know how to respond.

@lethalbit @minus
Ideas...
"Which normal?"
"Largest-to-smallest make sense to me."
"It makes sorting easier."
(On that last one - I got in the habit years ago of naming log and note files starting with the date, e.g. "2019-03-11_server-xyz-crash-notes.mdwn". It's easy, sorts well, lets me find stuff by topic *or* date with ls/find/locate/etc., doesn't rely on the filesystem timestamp or internal timestamps, etc.)

@minus see also RFC3339, which is an easy-to-parse subset of ISO 8601

@minus I decided to write a parser library that converted ISO-8601 strings to time.Time values in Go. Was a bit of a headache because there’s more than one way of representing a valid ISO-8601 time. I’m grateful that the spec exists, though!

@grawlinson @Wolf480pl I haven't actually read the spec, didn't think it could be so complicated from looking at the date+time version of the format on wikipedia

@minus S'how I always do it, so that an alphabetical sort will put them in correct chronological order. It also doesn't use any characters like / that can't appear in filenames on some OSs.

@minus

Isn't this only an American problem? Kind of like the imperial measure thing? I didn't think anyone else had these dates and measurement issues any more.

@minus I use my own format which is not standard but is slightly more human-readable and fail-safe:

2013-02Feb-27

It's still year-month-day, and the month name is always the same for a given month number, so it still sorts lexicographically, but it also reminds yyyy-dd-mm people that they're wrong

@CharredStencil For human use it's an interesting idea. It'd still be a pain to parse programmatically though.

@minus @CharredStencil You could just skip the month name when parsing it programmatically, so I don't think that'd really impact it. You could also filter out letters and then parse it as usual if you want.

@minus @CharredStencil

Using a #Perl6 #Grammar it would be something like this:

```
grammar D {
token TOP {
$<year> = \d+
"-"
$<month> = \d+
\w ** 3
"-"
$<day> = \d+
}
}

my $match = D.parse("2013-02Feb-27");

# The + in front of the matches converts them to Ints
is +$match<year>, 2013, "Year is correct";
is +$match<month>, 2, "Month is correct";
is +$match<day>, 27, "Day is correct";
```

The `\w ** 3` takes care of the 3-letter month notation.

@tyil @minus

"(%d+)-(%d+)[^-]*-(%d+)"

This Lua pattern returns the year, month, and day (multiple return) by ignoring everything between the month digits and the next hyphen.

So it also works with "2019-03-13" and "2019-03March-13"

@minus Several decades ago, at a day gig, I was in a meeting with an international team arguing about date formats. I said, sarcastically, "We'll use MM-DD-YYYY, because we're American, and we have more guns and money than anyone else." And I was jumped on immediately and indignantly called an "imperalist" by-- get this-- a Frenchman, an Englishwoman, and a German. Ahem.

Nowadays, any date format that isn't ISO and isn't UTC will get an immediate NOPE from me.

@minus at least the date and time of the apocalypse will be unambiguous

@minus

I actually prefer ISO 8601 over any other date format, even the one I grew up with.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!