Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack’s Incident on 2-22-22

slack.engineering

Post reply on HN
Print view View original

111–120 of 183 posts

Re: Slack’s Incident on 2-22-22

#111

Post by lkbm »

mulmen wrote: post #38
smegsicle wrote: post #5

Earlier quoted context omitted.

looks unambiguous to me lol

Ok, what is the format string? a) m-dd-yy b) m-yy-dd I can't tell. How do you disambiguate?

If you're trying to write a date parser for their outage report titles, the problem isn't the format of this date. It's that this is their only outage report with a date for the title.

It's the title because it's a novel date, and formatted this way to emphasize the novelty. It's also a date for which your question is irrelevant: it's the same either way.

Re: Slack’s Incident on 2-22-22

#112

Post by lkbm »

noselasd wrote: post #35
missedthecue wrote: post #22

Earlier quoted context omitted.

I mean, there is literally no way to confuse it with another date, unless you go back 100 years, when Slack didn't exist. There is no 22nd month, so we know the 22s are the day and the year, leaving only the 2 to be the month. Is it really that difficult to parse?

That particular date is possible to understand, but the date format is not. (Is is really that fun to try to figure out what 12-11-21 means ?)

Is there a different post where they used this date format?

None of their other incident reports even have a date in the title. Yet this one does, and in a weird format. Maybe there's something novel about the date, and it's written this was to emphasize the novelty, not to provide some vital information that happens to be excluded on every other incident report title they've posted.

Re: Slack’s Incident on 2-22-22

#113

Post by m-p-3 »

jonpurdy wrote: post #31
diarrhea wrote: post #11

That 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?

Came here to complain specifically about this. 2022-02-22 is unambiguous, big endian, and sorts nicely. IDK why society still uses any other date formats considering how international everything is.

ISO 8601 is IMO the only sane format.

Re: Slack’s Incident on 2-22-22

#114

Post by [deleted] »

diarrhea wrote: post #11

That 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?

[deleted]

Re: Slack’s Incident on 2-22-22

#115

Post by sverhagen »

mulmen wrote: post #108
sverhagen wrote: post #93

Earlier quoted context omitted.

So, European in the US, here. I switch my dates stubbornly to DD-MM-YYYY, 'cause that's the only way. Of course I would. But then there's so many US applications that don't adhere to my settings and use MM-DD-YYYY. So then I am still deciphering 05-07-2020-kind of stuff. All. The. Freakin'. Time. :)

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.

Re: Slack’s Incident on 2-22-22

#117

Post by throwdbaaway »

> Because the GDM data is immutable and thus can tolerate staleness, the query was also updated to read from replicas as well as Vitess primaries.

Any data that is fronted by the memcached caching tier can tolerate staleness right? There is not much difference between a short TTL of 1s versus an async replication delay of 1s.

Abusing vitess primaries is the root cause of this incident, and a similar incident can happen even without any scatter query.

Re: Slack’s Incident on 2-22-22

#118

Post by ascar »

lilyball wrote: post #72
ascar wrote: post #57

Earlier quoted context omitted.

> Europeans only got it a little better. There is a reasonable argument for little endian dates (as in the least significant information is usually the most relevant as it changes most often), but apart from the "it has been like this forever" I don't see any reasonable argument for middle endian date formats. Then again, the US is notoriously resistant to the metric system too.

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?

Edit: [1] says my hypothesis is most likely wrong, but that the UK just changed it later to match the rest of Europe. So maybe that influenced their way of speaking? In any case, matching the way one speaks doesn't seem to be a strong reason as it's easily adaptable and month names are unambiguous. Interestingly it also quotes that using a purely numeric format is incorrect in any formal use as to not confuse month and day.

[1] https://iso.mit.edu/americanisms/date-format-in-the-united-s...

Re: Slack’s Incident on 2-22-22

#119

Post by true_religion »

bee_rider wrote: post #56
true_religion wrote: post #27

Earlier quoted context omitted.

I think you meant Broker, but the misspelling is an act of genius since we are talking about downtime caused by an infrastructure failure.

Does it make it less of an act of genius if it was intentional?

No it’s be more an act of genius then. I think I meant something like serendipity.

Re: Slack’s Incident on 2-22-22

#120

Post by Wistar »

vxNsr wrote: post #70
58x14 wrote: post #66

Just 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…

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.]
Post reply on HN