since btime is omitted on Linux, maybe this would read better as 'Up to
four sub-elements are present, where'

+<code>atime</code>,<code>btime</code>,<code>ctime</code> and<code>mtime</code>
+ hold the access, birth, change and modification time of the volume, where known.
+ The used time format is&lt;seconds&gt;.&lt;nanoseconds&gt; since the beginning
+ of the epoch. This is a readonly attribute and is ignored when creating
+ a volume.<span class="since">Since 0.10.0</span>

It might be worth writing the regex to permit eliding the sub-second
resolution, on file systems that only have 1 second resolution. Given

Well, the problem here is that stat-time doesn't offer a way to
determine if sub-second resolution is available. If the system doesn't
support it then tv_nsec is simply zero. So there is always a sub-second
part in the timestamp and such an regex could be slightly misleading. I
will change it anyway and add a comment to the schema.

Doesn't gnulib guarantee that tv_nsec == -1 in isolation is sufficient
to point out an unknown value? That is, checking tv_sec == -1 is overhead.

Well, actually yes, but the the description on get_stat_birthtime says:
"Return *ST's birth time, if available; otherwise return a value with
tv_sec and tv_nsec both equal to -1.". So to be sure I prefer to check both.

Looking nicer. I'll have to ping upstream on gnulib about the last
holdout on the relicensing of stat-time; and I'm also still waiting for
the security fix in updated automake to hit Fedora.

Ok, please let me know if there are some changes here. Meanwhile I will
adapt my patch.