https://kotlinlang.org logo
#announcements
Title
# announcements
j

jw

07/09/2019, 9:09 PM
k

karelpeeters

07/09/2019, 9:14 PM
Ah it's actually a KEEP, I thought it was some one-off gist. Thanks!
n

Nir

07/09/2019, 9:17 PM
As far as I understand this KEEP is mostly about duration and timing related to measurement, timeouts etc. and not for real-world date/time application.
IMHO, this is a serious mistake
j

jw

07/09/2019, 9:17 PM
if you read it, that is addressed
n

Nir

07/09/2019, 9:17 PM
All these things are intricately related; your date time library should be fully interoperable with your language's "duration" type, and the duration type should be planned from the start to be compatible
Where is it addressed?
This is the closest thing I see to addressing it:
We believe that the API for working with date and times is a cornerstone thing and ideally it should be provided in the standard library. Unfortunately, the full blown date-time support is too heavy to be included in the stdlib, so we're trying to find a balance here. Duration and time measurement seem to have a moderate API surface and cover a lot of time use cases, so placing them in the stdlib looks reasonable.
j

jw

07/09/2019, 9:19 PM
yep
n

Nir

07/09/2019, 9:19 PM
This doesn't address what I'm saying.
Even if you put some stuff in the standard library, and some stuff not, it should still all be designed together
j

jw

07/09/2019, 9:20 PM
that is implied, yes, but also not strictly true in general and i don't think hyperbolizing it is useful
n

Nir

07/09/2019, 9:21 PM
Sorry, who is hyperbolizing?
j

jw

07/09/2019, 9:21 PM
there's two people in this conversation
n

Nir

07/09/2019, 9:22 PM
I'm not sure what I said that's hyperbolic
I've seen quite a few datetime libraries at this point across a couple of languages, nearly all of them are pretty bad, and one of the reasons why is because they tried to solve pieces of the problem at a time.
The one library I've seen that really nails everything is C++ date; currently the duration and epoch time are the only things standardized, but it was still designed in conjunction with the date/timezone stuff.
r

ribesg

07/09/2019, 9:24 PM
Why isn’t anybody freaking out on the KEEP adding extensions to
Int
,
Long
, etc
👆 2
j

jw

07/09/2019, 9:24 PM
but if you look at the ones which work, you'll note that they clearly have layers of abstraction which are can easily be carved into isolated pieces
@ribesg because it's a non-problem in theory and in practice. it's like complaining that there's toString() on them
n

Nir

07/09/2019, 9:25 PM
They have layers of abstraction... that were designed, taking the entire problem into account.
r

ribesg

07/09/2019, 9:25 PM
I get that but I like my autocompletes to be slightly shorter than an english dictionary
j

jw

07/09/2019, 9:26 PM
it's not clear why you're invoking something on a primitive instead of a semantic inline class at any frequency where it matters
r

ribesg

07/09/2019, 9:26 PM
For me extensions on base types is one of the main reasons people dislike klock
n

Nir

07/09/2019, 9:27 PM
It seems like the authors have not reviewed C++ date, based on some of the comments
Another approach that was considered is introducing the class TimeStamp and the arithmetic operations on it that return Duration. However, it was concluded to be error-prone because it would be too easy to mix two timestamps taken from unrelated time sources in a single expression and get nonsense in the result.
j

jw

07/09/2019, 9:27 PM
i'm sure they welcome your comments on the keep instead of this information silo of a Slack thread
👏 1
...on which i'm checking out
👋 1