Unclear tIME restrictions

[Oondanomala]

It seems logical that the timestamp in the tIME chunk would be restricted to only allow valid dates (e.g. disallowing February 29 if the year is not a leap year, or February 30), however the specification currently does not specify whether those dates are allowed or not, so it would be implied that they are. Should the wording be changed to explicitly disallow them? Or is it fine for them to exist?

Note that pngcheck does not currently allow invalid dates (see here).

(Technically one could also require the leap second to be valid, though they can't be predicted so it would not be feasible to do)

[ProgramMax]

The unspecified handling of invalid tIME might be intentional. I'm not sure there is anything we can specify, reasonably.

For example, if we say "the date and time must be valid" then we must also specify what it means to be (in)valid. There is surely another spec for time we can lean on for that.
But then we also need to specify what to do in case an invalid date/time is encountered. Should the entire image not be displayed? That's probably too drastic. A forensic app might want to flag it, though. So perhaps the handling is up to the app (read: unspecified).

I personally do like when the spec calls out "This is unspecified and the implementation is free to handle it how it deems best." though.

[svgeesus]

Pngcheck is a linter, designed to alert as many potential problems as possible. So for example it warns if the file modification tIME is before 1995 (ie before PNG itself was invented). Even so, there have been calls for more flexibility in reporting some things as warnings rather than errors. There is room for both approaches ("is this a valid, displayable PNG" vs. "is there anything here that could be fixed or improved").

I agree that requiring an image with an invalid modification time not be displayed is overly harsh. As the PNG specification says

When a fatal condition occurs, the decoder should fail immediately, signal an error to the user if appropriate, and optionally continue displaying any image data already visible to the user (i.e. "fail gracefully"). The application as a whole need not terminate.

When a non-fatal error occurs, the decoder should signal a warning to the user if appropriate, recover from the error, and continue processing normally.

@ProgramMax said:

I personally do like when the spec calls out "This is unspecified and the implementation is free to handle it how it deems best." though.

I agree, and we could add wording to that effect to the tIME chunk (and perhaps others where different handling for different purposes is expected).