Does anyone know why klock backs its datetimes wit...

# announcements

[Nir]

Does anyone know why klock backs its datetimes with double instead of integer? This is... Very odd. Is klock the standard for datetime stuff in kotlin?

[diesieben07]

Most likely for JS compatibilty, because JS has no native 64 bit int

[pardom]

Is klock the standard for datetime stuff in kotlin?

I don’t think there is a standard at this point. It would be nice if mpp dates were in the stdlib.

[Nir]

I didn't mean "standard" like in the standard library, more like "de facto standard" 🙂

[Nir]

@diesieben07 That's a very logical reason, but yikes!

[pardom]

Yeah, I don’t think it’s de facto either.

[Nir]

IMHO if you really need to deal with that, I would back it generically

[pardom]

I think it’s just the only option for MPP other than rolling your own dates.

[Nir]

MPP means kotlin native?

[diesieben07]

And JS

[Nicholas Bilyk]

multi-platform, not necessarily native

[pardom]

There’s a lot in klock that I don’t necessarily want to import.

[pardom]

I think there ought to be a project solely focused on the date implementation. Similar to this project solely focused on UUID https://github.com/benasher44/uuid

[Nicholas Bilyk]

I rolled my own, but I wouldn't recommend it.

[Nicholas Bilyk]

It gets hairy when you get to parsing and formatting

[pardom]

date/time is not a fun problem in general 😬

[diesieben07]

If you only need the JVM I can recommend just sticking with java.time, it works great

[Nicholas Bilyk]

you can create expect/actual methods for things like parsing and then defer to the platform's defacto implementation like js Intl package and jvm calendar stuff. It works well but you get implementation differences

[Nir]

Rolling your own just isn't realistic tbh

[Nir]

unless you only need very basic stuff

[Nir]

if you need to actually do timezone stuff for example it's a non-starter

[Nir]

writing a parser for the IANA database, etc

[pardom]

I looked for the IANA DB in Klock, but didn’t see it. Did I miss it?

[Nir]

@pardom what do you mean, solely the date implementation? what is klock if not that?

[Nicholas Bilyk]

by 'rolling my own' I meant just writing apis that give you a common way to access the different backends

[Nicholas Bilyk]

and then the backends have the normal way they do time

[pardom]

@Nir what I meant by that was a way to retrieve time.

[pardom]

I was unclear about that.

[Nicholas Bilyk]

just a timestamp or do you need to format it?

[Nir]

What is the "de facto" implementation on native?

[Nir]

The C stuff is not good to say the least.

[Nir]

@pardom Having seen multiple implementations that went badly wrong, I'd have to say I disagree. time, dates, timezones, all needs to be planned as one library.

[Nir]

It's very hard to retrofit things later, design wise.

[Nir]

These things are intimately connected, so logically you are going to arrive at a better overall design if you take it all into consideration at once

[Nir]

I think you are right, I don't think klock actually has TZ support 😞

[Nir]

As for 1.0 Klock doesn’t have direct TimeZone support. But support offseted DateTime using DateTimeTz.

[Nir]

So, both python datetime and C++ boost datetime started with approaches like this... and both are a total mess to use once you need "real" timezone support.

[gildor]

klock is not a standard and not even “de facto” standard, is just a community library, there are plans for full-blown date/time library for MPP, but it doesn’t exist yet, for now just better to use platform specific API with own MPP wrapper

[Nir]

@gildor this is fine on the JVM but e.g. for native, using the C stuff is a disaster.

[gildor]

yes, there is no perfect solution indeed

[Nicholas Bilyk]

couldn't you use any C library you wanted on the C backend?

[Nir]

I'm just not aware of any really good C library solution for this.

[Nir]

You could probably find something that would be correct, but the API, type correctness, etc, of the library, would be very poor (because it's C)

[Nir]

It would be a massive step down from e.g. C++ date, or the java libraries

[karelpeeters]

I think one of the JB guys posted a preliminary date/time API design to ask feedback on about a month ago, but I can't seem to find it. Does anyone have the link?

[karelpeeters]

So, what I wanted to say: look like the plan for the Kotlin stdlib is to store it as a double as well: https://github.com/Kotlin/KEEP/blob/durations/proposals/stdlib/durations-and-clocks.md#duration

[Nir]

@karelpeeters thanks for linking, I wrote a pretty long reply on the thread

[karelpeeters]

You should write that reply on the issue 😛

[Nir]

Yeah, definitely not a fan of the double thing

[Nir]

I did

[Nir]

Check it out 🙂

[Nir]

https://github.com/Kotlin/KEEP/issues/190