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 a day 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 a day ago | parent [-]

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

▲

swsieber a day 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 a day 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.

	▲	M95D 5 hours ago \| parent [-]
		A datestamp is a privacy risk. If it's optional, don't include it. If it's not optional, it's a spec bug! It should be optional. Or even better, removed entirely.