Earlier quoted context omitted.
The fact that the current top comment thread is quibbling about the date format in the title seems to agree with this assessment, if there was anything real to complain about that’s what we’d be seeing, instead we get bikeshedding on the date format in the title of a post.
[adds "bikeshedding" to vocabulary.]
Slack’s Incident on 2-22-22
151–160 of 183 posts
Re: Slack’s Incident on 2-22-22
#152Earlier quoted context omitted.
It's because it matches the way we speak dates aloud. When intended for human consumption, sortability and big-endianness doesn't matter, but matching the way we speak does. Maybe other cultures actually speak dates differently, I don't know, but I have never seen a native English speaker habitually speak dates any differently than "January 1st, 2001". All that said, I definitely agree with the original complaint, m-…
Given that so many (all?) other English speaking nations including the UK usually speak it the other way around and write it day-month-year, I wonder if writing (especially thinking about newspapers here) influenced the way you speak it and not the other way around. March 1st saves space and ink over 1st of March or some other rationale. Someone certainly has already investigated the origin of putting the month first…
Re: Slack’s Incident on 2-22-22
#153Just my personal take, I think this is a really well-written incident postmortem. It's specific, extensive, candid, and dare I say, entertaining? Many incident reports are fully lacking in any meaningful detail, or wholly unapologetic. I actually enjoyed learning tidbits about the author, in particular their mention of https://how.complexsystems.fail/ . Reading this boosted my confidence in Slack's teams, which shoul…
Re: Slack’s Incident on 2-22-22
#154Earlier quoted context omitted.
For the whole of Europe it would be 22.02.2022, how is all of Europe statistically insignificant?
The official EU rules say 22.02.2022, but nobody in Europe would have trouble parsing 22/2/22 or any variation thereof. And the / (or -) separator is indeed used in parts of the EU. It’s the ordering that’s significant, not the separator.
A mixture is even more likely to be d-m-y, today is 27/4-2022 in Danish handwriting.
Re: Slack’s Incident on 2-22-22
#155Earlier quoted context omitted.
European date format doesn’t make sense either. It still doesn’t sort and the little-endian date is composed of big-endian year, month, and day. Putting the day first isn’t actually a benefit because you still need the year and month for context. Any favoritism of the EU format is the same as the US format. Just familiarity. ISO8601 is the only way.
I agree that the European format is probably not more useful, and you probably convinced me to go change my settings to YYYY-MM-DD. But I _do_ think that the European format makes more _sense_, it being in chronological "magnitude" order.
Since you are already on the fence with ISO8601 I invite you to consider time of day. Would you use second:minute:hour? That is also in (reverse!) “chronological magnitude” order.
Re: Slack’s Incident on 2-22-22
#156Earlier quoted context omitted.
I can say with certainty this isn't strictly true. The failures should be relatively rare; when I say relatively I mean on the level of natural node failure. If natural node failure isn't survivable without special systems to quickly replace downed nodes you don't actually have an N+1 redundancy system. Thus, the pools aren't large enough :) Or, in this case, if they really are failing this much then having them alwa…
> The failures should be relatively rare; when I say relatively I mean on the level of natural node failure. And exactly how rare do you believe this to be? In my experience, node failures at scale of hundreds to thousands of nodes are monthly to weekly, if not daily. Generally speaking, stability is a normal distribution. Young, new instances experience similar failure rates as old instances. If you have any sort of…
But that generally mirrors my experience that automatic failover for stable software tends to cause more issues than it solves. A good (i.e. redundant hardware and software) Postgresql server is also so unlikely to fail that wrong detection and cascading issues from automatic failover are more likely than its actual benefits.
Re: Slack’s Incident on 2-22-22
#157Just my personal take, I think this is a really well-written incident postmortem. It's specific, extensive, candid, and dare I say, entertaining? Many incident reports are fully lacking in any meaningful detail, or wholly unapologetic. I actually enjoyed learning tidbits about the author, in particular their mention of https://how.complexsystems.fail/ . Reading this boosted my confidence in Slack's teams, which shoul…
Re: Slack’s Incident on 2-22-22
#158That date format is actually the worst I have ever encountered. m-d-y, with year in 2 digits, numbers not zero-padded, US "order" yet using dashes. It's like a moderator of /r/ISO8601 came up with the worst possible format on purpose . Am I missing something?
Re: Slack’s Incident on 2-22-22
#159Re: Slack’s Incident on 2-22-22
#160Earlier quoted context omitted.
For the whole of Europe it would be 22.02.2022, how is all of Europe statistically insignificant?
The official EU rules say 22.02.2022, but nobody in Europe would have trouble parsing 22/2/22 or any variation thereof. And the / (or -) separator is indeed used in parts of the EU. It’s the ordering that’s significant, not the separator.
Yeah, I guess if people look at it and parse it, they understand it. But what I notice is, that the IT-bubble I am in has no worries parsing these dates because we use them a lot in IT, even in Europe. But people outside of IT do seem confused about US-formatted dates from time to time, because they rarely encounter them.
More than once did I notice someone struggling to fill in their birthday into an online form because the people making the form decided to use M/D/Y instead of D.M.Y Of course most can help themselves, but its not like these date formats seem natural or normal to everyone in Europe.