0

In my golang application I'm using a Unix second-resolution timestamp (generated with time.Now().UTC().Unix()) as part of a salt in the hash function used for request authentication.

There's a desire to store this timestamp in a datastore, where the convention is RFC3339 nanosecond-resolution timestamp strings generated by the golang RFC3339Nano function, along with the hash for authentication.

The question: Is there any risk that the RFC3339Nano can't be reversed exactly to the original Unix timestamp, in the event that the hash needs to be reauthenticated later?

I know there are some issues with leap seconds which apply to Unix timestamps; is it ever possible that round-tripping through RFC3339Nano will result in a different timestamp, thus erroneously invalidating the signature?

The RFC3339Nano timestamp and the Unix timestamp are generated from the same time.Time struct.

I'm inclined to think it will work since leap-seconds spawn an extra 61st second at the day of their occurrence, which I expect would map back to the same Unix timestamp as the previous second. The reverse would clearly fail though.

Techrocket9
  • 2,026
  • 3
  • 22
  • 33

1 Answers1

0

I think you suffer this kind of trouble with no reason, why don't you just use the Unix() directly store to the database and restore with that?

Cytown
  • 1,539
  • 9
  • 7
  • The convention of the service is to serialize all timestamps to RFC3339Nano format. I'm willing to break convention if necessary, but I want a case for why it's necessary. – Techrocket9 Mar 20 '19 at 16:31