Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ukstv
Copy link
Contributor

@ukstv ukstv commented Jun 29, 2023

Rely on POSIX specification to convert between UTC and unix timestamps.

@ukstv ukstv requested review from oed, bumblefudge and ligi June 29, 2023 15:52
Comment on lines +331 to +332
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.
Copy link
Collaborator

@oed oed Jun 29, 2023

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.

  1. If we have timeRFC, how do we get timeUnix and timeTzAndMills?
  2. If we have timeUnix and timeTzAndMills, how do we get timeRFC?

Basically how do we separate the one timestamp into the two fields and vice versa.

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

Copy link
Collaborator

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)

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

Copy link
Collaborator

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!

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh shoot. Right.

@obstropolos
Copy link
Contributor

cc @chunningham

@bumblefudge bumblefudge marked this pull request as draft July 27, 2023 15:20
@bumblefudge
Copy link
Collaborator

we should close #235 with this PR too (he says as if he's going to help)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants