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.

▲

ssl-3 an hour ago | parent | next [-]

Other things were reported to successfully be printed on Tuesdays, so that inclusion (or at least, this form of it) is empirically unnecessary.

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

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

▲

notatoad an hour ago | parent [-]

>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.

▲

adrianN an hour ago | parent [-]

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

	▲	swsieber 42 minutes ago \| parent \| next [-]
		I have. I don't like it. I'd rather have the ability to debug, redundant checks, etc. than only what's truly necessary.
	▲	notatoad 33 minutes ago \| parent \| prev [-]
		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.

▲

gpvos an hour ago | parent | prev | next [-]

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.

▲

bombcar an hour ago | parent | prev [-]

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.

▲

bitwize an hour ago | parent [-]

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).

	▲	ssl-3 an hour ago \| parent [-]
		It's important that software behaves well on systems with bugs. (All systems have bugs.)