-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add timestamp conversion for CACAOv3 #233
base: main
Are you sure you want to change the base?
Conversation
Unix timestamp is defined in [POSIX specification](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) (as defined in The Open Group Base Specifications Issue 7, 2018 edition or IEEE Std 1003.1-2017). | ||
It is derived from UTC: regardless of leap seconds, a day has to have 86400 seconds. We can rely on a conversion algorithm provided by an operation system thus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice with some more detail here.
- If we have
timeRFC
, how do we gettimeUnix
andtimeTzAndMills
? - If we have
timeUnix
andtimeTzAndMills
, how do we gettimeRFC
?
Basically how do we separate the one timestamp into the two fields and vice versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of trying to split up the timestamp, could we instead just keep the whole timestamp in the fields? e.g.
fct: {
iat-enc: "1985-04-12T23:20:50.52Z"
exp-enc: "1990-12-31T15:59:60-08:00"
}
and require that the unix time of these matches those in iat
, exp
and nbf
? it makes these fields slightly longer, but obviates the need for multiple fct
fields per time field (i.e. instead of iat-tz
and iat-mills
we just have iat-enc
), and also covers every base
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats the benefit of this though? We still need to do the conversion of the unix timestamp for verification.
I also never suggested two fct
fields. would be more something like:
issued-at
(RFC) turns into iat
and fct.z-iat
(the latter would contain both milliseconds and TZ info)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I misunderstood, so we would represent everything after the seconds part? e.g.
1985-04-12T23:20:50.52Z
=> .52Z
1990-12-31T15:59:60-08:00
=> -08:00
1990-12-31T15:59:60.52-08:00
=> .52-08:00
In that case it seems to do the trick
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes exactly. And that's what I was hoping this appendix section would cover!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might miss or forget some discussion about timezones? Why does one need that? Also, milliseconds - are we in a high-frequency trading realm?
Unix timestamp is UTC (±1 second). You could always convert UTC to another timezone. A wallet definitely knows better how to display a timestamp in a user-friendly way, be it ISO8601 format or "20:00 next Monday".
Why do we have that even in CACAO spec instead of relying on a unix timestamp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might miss or forget some discussion about timezones? Why does one need that?
SIWE supports the message having tz info
Also, milliseconds - are we in a high-frequency trading realm?
No but SIWE messages support it so we also need to in this conversion algo. We need to describe it precisely here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh shoot. Right.
cc @chunningham |
we should close #235 with this PR too (he says as if he's going to help) |
Rely on POSIX specification to convert between UTC and unix timestamps.