-
Notifications
You must be signed in to change notification settings - Fork 327
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
Use kotlinx.datetime for time handling #272
Conversation
4e46b1f
to
f5120a1
Compare
228ef82
to
b917dbd
Compare
b917dbd
to
d077a3a
Compare
val isLightning: Boolean = endsAt - startsAt <= LIGHTNING_TALK_LIMIT | ||
} | ||
|
||
val SessionCardView.isLive get() = state == SessionState.Live | ||
val SessionCardView.isUpcoming get() = state == SessionState.Upcoming | ||
val SessionCardView.isPast get() = state == SessionState.Past | ||
|
||
val Session.isLightning: Boolean get() = endsAt.timestamp - startsAt.timestamp <= 15 * 60 * 1000 | ||
val Session.isLightning: Boolean | ||
get() = endsAt - startsAt <= LIGHTNING_TALK_LIMIT |
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.
minor: isLightning
check is duplicated
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.
We need this both on Session
and SessionCardView
, I think with the limit variable extracted at least it's alright like this
import java.time.Clock | ||
import java.time.LocalDateTime |
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.
Is java.time
still needed 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.
The backend code still uses java.time
APIs in a bunch of places, I tried touching as little of the backend code as possible. Only edited the parts that were tightly coupled to the shared code.
We could rewrite the backend to be all kotlinx.datetime
too, but it's not strictly necessary. Just wanted to have these types on the client side instead of using the Ktor GMTDate
type everywhere.
@e5l to review the backend changes though, and whether we want more of them.
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.
Feel free to use kotlinx.datetime if it's possible
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.
Okay, then I think it is fine to merge this PR as is and log an issue for backend refactoring.
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.
lgtm
import java.time.Clock | ||
import java.time.LocalDateTime |
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.
Feel free to use kotlinx.datetime if it's possible
d077a3a
to
1b57a7a
Compare
1b57a7a
to
e986d67
Compare
No description provided.