I'm not sure. Does the feed have a rate limit?

@Bookends Lol, I'm actually considering doing that.

Alternatively, we could create rooms for different subgroups of sites...

That's gonna be a lot of work though.

One thing that's pacifying is that I had set up a separate feed for Physics, using rene's URL. It catches all the HNQs perfectly (only for Physics though).

So, if needed we can at least set up separate feeds for each site.

Well, no worries. I'll do some experiments and check. It's not a big deal. :P

At least, I'm glad it's working for the physics site (which was my original aim anyway).

Cya!

Yes, but... 02019-02-14 only postpones the inevitable.

@MEEisJohannGambolputty... ISO 8601 requires a four digit year at minimum, 356 would be 0356.

> To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver. An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[20] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.

Ugh. Prior agreement...

Also ugh because putting + in front makes is string-sort before the 4-digit years. If it was a character positioned after 9, like @, then lexicographic order would still match the chronological: @10000 comes after 9999.

They blew a chance to delay Y10K problem until Y100K problem.

If you want to know why things work the way they do... but don't want math... 🤔

That's tough. But at least there is Data Science which is kind of like a mix of two - you get neither explanation nor teh codez.

Since @mentions do not count toward the length of a tweet, but are included in a onebox... we could have some truly juge oneboxes in here.