Add epoch time to json snaphot keys

When requesting json response from snaphot the json returns a formated timestamp which is ok but i want to filter snapshot records and thus will have to parse this back to epoch time. If restic stored/returned an additional epoc time field/key that would be great. Formated times can change which would break a parser but not epoch time which is just a number. In general I never store formatted timestamps as they can always be generated from epoch timestamp field in whatever the end user desires.

If this is worthy feature I’ll set an issue.

  {
    time: '2021-03-12T09:42:58.34054478-08:00',

to

  {
    time: '2021-03-12T09:42:58.34054478-08:00',
    epoch: 1615578420,

well at least in ndoejs there is moment package with which I can do

snapshot.epoch=moment(snapshot.time, 'YYYY-MM-DD HH:mm:ss').valueOf()
{
  time: '2021-03-12T12:15:31.130627984-08:00',
  parent: '9230dec7ee2fc3fcb18ce16478a066855b89d400562729c0e25525ebd6d910d5',
  tree: 'bf3200038703955f471655ee1fea7ea9ae49cc36ad0e03261dd5579f4b27727d',
  paths:,
  hostname: '',
  username: '',
  uid: 1001,
  gid: 1001,
  id: '1ff52a5ac58cec896808238c5b2b5f1255822c8f29d941fa7030105807693a20',
  short_id: '1ff52a5a',
  epoch: 1615580131000
}

which works for now

I’m not sure this is that necessary. The timestamp format used is compatible with ISO 8601, which should be acceptable just about everywhere. In fact, JavaScript’s native Date object can parse it:

> new Date('2021-03-12T09:42:58.34054478-08:00')
2021-03-12T17:42:58.340Z

I’ve occasionally wanted epoch too since jq’s fromdate builtin doesn’t like ISO8601 dates that specify an offset (or probably fractions of a second either):

jq: error (at :1): date “2019-10-16T23:29:44.6521869-05:00” does not match format “%Y-%m-%dT%H:%M:%SZ”

Though maybe what I really want is just more control over the textual date format.

Hmm, that’s a good point – though it makes me wonder if that would be better handled as a bug report / feature request against jq, as I can’t imagine that others haven’t run into this same issue with jq. Having jq support the full ISO 8601 standard would (IMO) be more useful to more people than having restic output timestamps in a second format.

Edit: Looks like there is an open request… from 2015 :frowning: