Doesn't seem to me like it is telling the printer what day of the week it is because the printer needs to know so much as it is generating a PostScript file for the printer to use and is adding the creation date as either a convention or requirement of the format, and not the printer.

Exactly, it was using the file utility to determine what it was so it could print it correctly (by processing it if needed to a format the printer understood) and there was a bug in that.

This is one of those "VLC is slow to start because of a bug in Windows" things. It's VLC's responsibility to ensure their program runs properly on the OS people actually have. It's LibreOffice's responsibility to ensure that their files print on Tuesday irrespective of bugs in CUPS (which ships with the Mac).

It's important that software behaves well on systems with bugs. (All systems have bugs.)

So, Windows gets a pass for being sloppy coded? Give me a break. Every software must fulfill their contract with every consumer rather than consumer have to work around producers quirks. "All means are fair except solving the problem"[0]

0: https://yosefk.com/blog/all-means-are-fair-except-solving-th...

Not a requirement, but indeed more of a convention or at least a possibility. Postscript files can be postprocessed or read by humans, and then this kind of metadata can be useful.

Other things were reported to successfully be print on Tuesdays, so that inclusion empirically unnecessary.

And the whole CreationDate field is optional in PostScript[1], anyway.

[1]: https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf

>so that inclusion empirically unnecessary

this seems like a post-rationalization. when an app generates a file to send to another service, it's usually a good practice to timestamp that. unless you're severely bandwidth-constrained, putting a timestamp in your protocol almost always solves more problems than it creates. "we shouldn't include a timestamp because it might at some point trigger a date-math bug" is just not how software gets built.

the fact that the software can still print without including a timestamp doesn't mean it's not worth including.

Maybe we should think about building software in a way that only adds stuff that is truly necessary.

I have. I don't like it. I'd rather have the ability to debug, redundant checks, etc. than only what's truly necessary.

if this bug was caused by a lack of a datestamp instead of the inclusion of one, you'd be here leaving comments about how silly it was they didn't include something as standard and widely useful as a datestamp, and that of course that was necessary.

Can be useful to distinguish when a print job was submitted from when it was actually received by the printer. That distinction matters when printers go offline and jobs get queued.

Is it possible or practical to examine a printer's internal queue for jobs that might include this (completely optional) CreationDate field?

If not, then: I'm not sure that the distinction means anything. :)

Yes. Many printers have a web interface where you can see active jobs, job history, timestamps, and document information. Some even have a physical control panel that lets you inspect this information directly from a touchscreen.