Failure to parse subsecond precision timestamps #185
Description
@1668384000 is parsed fine, but @1668384000.0 is not; also of course .1 is not parsed correctly and I'm not sure it can be rendered?
(Tested as of main branch commit 5d869b5, current at time of bug report)