Difficult to override display format of domain produced timestamp values in zonefile output.

[ximon18]

domain enables rendering of resource records in zonefile format via the zonefile_display() fn provided by impls of the ZonefileFmt trait.

For RRSIG inception and expiration timestamps this causes the timestamps to be rendered as UNIX seconds since the epoch integer values which is valid according to RFC 4034 section 3.2, but other tools render these as YYYYMMDDHHmmSS in UTC which is also valid according to RFC 4034 section 3.2. This was probably chosen as the behaviour in domain because it is faster to render than doing integer to YYYY... string conversion, especially considering edge cases such as leap years.

The actual formatting is not even RRSIG specific, it is done at the Timestamp type level.

If an application using domain wanted to produce YYYY... format, it would either have to render RRs in zonefile format itself, knowing which RTYPEs it needs to override behaviour for and knowing how to render all of the data for that RTYPE, or else it would have to parse the generated zonefile format and find and "edit" the timestamp part.... both are pretty horrible.

An alternative would be to further extend ZonefileFmt so that it supports not just multiline, tabbed or simple DisplayKind but also has a notion of how to render timestamps (and probably a dependency on a time library being needed then as well so hide it behind a feature gate).

Given this is a niche use case and a bit of work to add and doesn't produce output that is any more valid than what is already produced I wouldn't bother capturing it at all, except for the fact that for users who do care it is not trivial to work around.

[Philip-NLnetLabs]

I guess anybody who has scripts that parse the output of ldns tools can get in trouble if our replacement tools suddenly have a different format. Though I guess this should be a discussion at dnst to see if compatibility warrants making changes in domain.