Add enforcedTimestamp option

[zner0L]

I use a modified version of your plugin (zner0L/postcss-fonticons) and ran into a problem, because the generated CSS was a little different every time it was built. This was bad for caching, since those little changes still invalidated the caches. After some digging, I found that the changing bits were actually svg2ttf's timestamps in the generated fonts. This PR exposes their option to overwrite timestamps to get dependable results in every build.

[jantimon]

Cool - what do you think about not using an additional option but using the latest timestamp of all used svgs?

That way the timestamp is kind of more correct and it is less work to configure it.

[zner0L]

Are you talking about the timestamps of the files or some timestamp inside the XML? I guess this would be a nice default value, though the option should still be configurable (e.g. in the case where the svgs are also auto generated each build). I think having a default value here is actually sensible because most users would actually want reliable caches for their build pipelines. (And also – the timestamp in the TTF is not really important for anything really)

[jantimon]

I agree - this timestamp is quite useless.. Can we maybe use a hardcoded value? e.g.: 1.1.2000?

[kaidjohnson]

I have been looking into why our builds have a non-deterministic [contenthash] of our .css files and narrowed it down to this exact issue. However, I'm not sure the proposed solution fits the goal of the project:

This plugin tries to keep the usage and maintenance of icon fonts as simple as possible.

I can't see a use-case where defining the timestamp would be useful (it doesn't end up in the base64-encoded output) nor can I see a use-case where not defining the timestamp would be useful (each build generates a new hash for no reason). As such, I'd like to propose that the plugin simply set a static timestamp:

    .then((svgFont) => svg2ttf(svgFont, { ts: 0 }).buffer)

The ts option in svg2ttf should be the number of milliseconds since the unix epoch, so setting it statically to the beginning of the epic should suffice.

As such, I've opened #64 as an alternative to this PR.