-
Notifications
You must be signed in to change notification settings - Fork 68
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
Refactoring of Timestamp #283
Refactoring of Timestamp #283
Conversation
|
||
private[this] def appendNano(nano: Int, s: java.lang.StringBuilder): Unit = | ||
if (nano != 0) { | ||
val y1 = nano * 1441151881L // Based on James Anhalt's algorithm for 9 digits: https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/ |
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.
thanks for inlining a reference to the algorithm !
} | ||
|
||
/** Has platform specific implementation */ | ||
private[this] def formatHTTPDate: String = { |
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.
out of curiosity, what makes it platform specific ? From a quick look, it seems like it would cross-compile, so I presume it's a case that this implementation would not be optimal on JS.
If I want to cross-publish to Native, will I be able to share the sources between JVM and Native ?
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, the current draft is not optimized for any of platforms.
I'm going to have own Timestamp sources for each platform.
If JVM version should run on JDK 8 then it will be the same as for Scala Native.
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.
If JVM version should run on JDK 8 then it will be the same as for Scala Native.
Coo. I don't want to assume you'll have time to dedicate to implementing both a JDK 11+ and a SN-compatible version, so let's do JDK 8 for now
I'm happy with the direction this is taking 👍 |
217bb65
to
cead116
Compare
cead116
to
23ee362
Compare
…latforms accordingly
2504300
to
65fc57f
Compare
65fc57f
to
ccc6f3e
Compare
47639b2
to
458f4f0
Compare
458f4f0
to
76a53fd
Compare
…m/to JSON for the EPOCH_SECONDS format
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.
Thank you so much for this 👍
@plokhotnyuk can you share more context on this? Looks like the default |
The reason of decreasing the range of allowed values for |
Goals for refactoring of
smithy4s.Timestamp
:The range of allowed values reduced to be from
0000-01-01T00:00:00Z
to9999-12-31T23:59:59Z
.Below are results of benchmarks for parsing and serialization of array of 128
java.time.Instant
values using JSON codec forsmithy4s.Timestamp
on Intel® Core™ i9-11900H with JDK 17.Before:
After: