[metrics-team] What does first_seen="1970-01-01 00:00:00" mean in an Onionoo bridge details document?

[David Fifield]

Some Onionoo bridges have first_seen="1970-01-01 00:00:00", while
last_seen and last_restarted are set to reasonable dates. For example,

https://onionoo.torproject.org/details?type=bridge&limit=100&fields=hashed_fingerprint,first_seen,last_seen,last_restarted
{"hashed_fingerprint":"29AC664582027DFAF94528F989951D68115252F0","last_seen":"2016-12-14 14:41:03","first_seen":"1970-01-01 00:00:00","last_restarted":"2016-11-15 15:12:39"},
{"hashed_fingerprint":"4E0727172580EE302138D3DD33A04CD23D650F0F","last_seen":"2016-12-10 08:41:03","first_seen":"1970-01-01 00:00:00","last_restarted":"2016-12-09 09:06:38"},

What does this mean? I never saw "1970-01-01 00:00:00" in the other two
date fields, only in first_seen. I would expect, based on the
documentation, that if a bridge had been seen in only one bridge network
status, that first_seen would equal last_seen.

https://onionoo.torproject.org/protocol.html#details
> * last_seen string required
>   UTC timestamp (YYYY-MM-DD hh:mm:ss) when this bridge was last seen
>   in a bridge network status.
> * first_seen string required
>   UTC timestamp (YYYY-MM-DD hh:mm:ss) when this bridge was first seen
>   in a bridge network status.

I looked briefly at the onionoo source code. The only explicit reference
to "1970-01-01 00:00:00" I found was in in
org.torproject.onionoo.docs.UpdateStatus.setFromDocumentString, when a
timestamp fails to parse.
https://gitweb.torproject.org/onionoo.git/tree/src/main/java/org/torproject/onionoo/docs/UpdateStatus.java?id=onionoo-3.1-1.0.0#n24
>   public void setFromDocumentString(String documentString) {
>   try {
>     this.updatedMillis = Long.parseLong(documentString.trim());
>   } catch (NumberFormatException e) {
>     log.error("Could not parse timestamp '" + documentString + "'.  "
>         + "Setting to 1970-01-01 00:00:00.");
>     this.updatedMillis = 0L;
>   }
> }

I was able to find one of the hashed_fingerprints above in a recent
bridge status document (published 2016-12-14 09:41:03). It looks okay to
me, so I don't suspect it's a parsing issue.

29AC664582027DFAF94528F989951D68115252F0:
r Unnamed KaxmRYICffr5RSj5iZUdaBFSUvA 0PeiGiVwFHDcaLTK4UYpZQXhaYg 2016-12-14 12:57:51 10.107.79.18 53924 0
s Fast HSDir Running Stable V2Dir Valid
w Bandwidth=60
p reject 1-65535