-
Notifications
You must be signed in to change notification settings - Fork 3
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
Implement Duration
normalization - Part 1
#20
Conversation
e7f92f0
to
08f7251
Compare
08f7251
to
2218d49
Compare
Duration
normalizationDuration
normalization - Part 1
I'm seeing the spec corrections make it possible to do the computations using 128bit integers. Will we transition to that representation in the future? (32 bit components + 128 bit normalized repr) |
Yeah, I think it did. To be frank, I haven't put too much thought into it as of yet. Mostly because I would really like to have a lot more of the spec implemented and some more tests in place to mitigate any edge cases or oddities that may arise off the switch. Since |
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.
Pretty straightforward changes, mostly because it's closely following the spec. I just have a single suggestion that doesn't block merging this.
65b4a84
to
daaae7d
Compare
This draft PR is meant to eventually address #19
Currently, this PR is small baseline changes focused on
NormativeTime
records andbalance
methods (EDIT: it also addsCalendarDateAdd
functionality for theISO8601
).The changes overall are pretty widespread across large sections ofDuration
that could really use more tests, so the plan is to come back to this once it can be tested a bit more or split it into a couple of PRs.I'm going to switch this into a normal PR from a draft. After looking through it, #19 will still need to be implemented in a couple PRs, but I think it makes more sense to break the overall update down into smaller chunks