@ebassi
Copy link

ebassi commented Jan 15, 2016

UNIX epochs are a terrible way to specify a date and time, especially in a human readable and writable data format.

UNIX epochs have too high granularity for release metadata: I don't care if I released something less than a minute ago, and if something takes less than a second to release then something is clearly wrong. UNIX epochs have no actual size specified, so they could be loaded by 32 bit architectures or 64 bit ones; the AppStream API already has to use 64 bit wide unsigned integers to cope with this.

UNIX epochs do not have timezone information, as they are (generally, see below) relative to coordinate time; this means that I lose the timezone information of a release whenever I use the UNIX timestamp.

UNIX epochs are poorly defined, as there are a bunch of those - with leap seconds, without leap seconds, from UTC, from TAI, etc. You're basically encoding the behaviour of the date +%s command on your current OS whenever you use one.

Humans do not know how to write UNIX timestamps; you need an ancillary tool to write them and read them, thus introducing undeclared dependencies.

Humans have invented the ISO 8601 specification, which is what everyone should be using to represent dates and times (and intervals) inside exchange formats.

The <release/> tag in the release metadata should deprecate the timestamp attribute in favour of a new time attribute, which expresses the release time as an ISO 8601 string. The AppStream library API does not need to be modified, as it can convert to and from ISO 8601 dates transparently.