<https://github.com/Kotlin/KEEP/pull/191>

# announcements

[jw]

https://github.com/Kotlin/KEEP/pull/191

[karelpeeters]

Ah it's actually a KEEP, I thought it was some one-off gist. Thanks!

[Nir]

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.

[Nir]

IMHO, this is a serious mistake

[jw]

if you read it, that is addressed

[Nir]

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

[Nir]

Where is it addressed?

[Nir]

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.

[jw]

yep

[Nir]

This doesn't address what I'm saying.

[Nir]

Even if you put some stuff in the standard library, and some stuff not, it should still all be designed together

[jw]

that is implied, yes, but also not strictly true in general and i don't think hyperbolizing it is useful

[Nir]

Sorry, who is hyperbolizing?

[jw]

there's two people in this conversation

[Nir]

I'm not sure what I said that's hyperbolic

[Nir]

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.

[Nir]

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.

[ribesg]

Why isn’t anybody freaking out on the KEEP adding extensions to Int, Long, etc

[jw]

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

[jw]

@ribesg because it's a non-problem in theory and in practice. it's like complaining that there's toString() on them

[Nir]

They have layers of abstraction... that were designed, taking the entire problem into account.

[ribesg]

I get that but I like my autocompletes to be slightly shorter than an english dictionary

[jw]

it's not clear why you're invoking something on a primitive instead of a semantic inline class at any frequency where it matters

[ribesg]

For me extensions on base types is one of the main reasons people dislike klock

[Nir]

It seems like the authors have not reviewed C++ date, based on some of the comments

[Nir]

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.

[jw]

i'm sure they welcome your comments on the keep instead of this information silo of a Slack thread

[jw]

...on which i'm checking out