Is there a shorter way to get a "today" `Instant`?...

# kotlinx-datetime

[ribesg]

Is there a shorter way to get a "today" Instant? In particular, repeating the timezone twice feels a little weird

Clock.System.todayIn(TimeZone.UTC).atStartOfDayIn(TimeZone.UTC)

[ephemient]

you could operate inside java.time with types that carry timezone information along,

OffsetDateTime.now(Clock.systemUTC()).truncatedTo(ChronoUnit.DAYS).toInstant().toKotlinInstant()

[ribesg]

Forgot to say I'm in multiplatform, I don't have java.time

[Awkin]

There's no "today" instant, it depends on the time zone: https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime/today-in.html What your code finds is the start of the day in Greenwich.

[Awkin]

Why is the start of the day in Greenwich specifically important for your business logic?

[ribesg]

I'm dealing with a database created and managed by PHP code and you know PHP developers: they use only one kind of date for times, dates, datetimes, local, offset or zone, in all cases it's an OffsetDatetime stored as a half extended half basic iso datetime String that I need to have a custom formater for.

In my case I actually want to store a local date so the timezone doesn't matter, and I managed to convince them to store local dates with the UTC timezone (or actually the +0 offset). I'm trying to figure out if I need to make a wrapper lib to handle our weird usages of dates or not in Kotlin. I previously made my own multiplatform Date type and I am replacing it with kotlinx.datetime. For now I only made a lib for the formatter and serializer. I don't think I need more

[ribesg]

Obviously if I didn't have to deal with all that old crap I would use proper typing, both in my code and in the database, which does have a date type 😞

[Awkin]

store a local date so the timezone doesn't matter

A local date in your own time zone, you mean? Shouldn't the code then be

Clock.System.todayIn(TimeZone.currentSystemDefault()).atStartOfDayIn(TimeZone.UTC)

?

[ribesg]

Absolutely not. A local date doesn't have a timezone, that's the very definition of it.

[Awkin]

2024-01-04 does not have a time zone, by definition, sure, but the date of the current moment (what you get from Clock.System) is different for different time zones.

[ribesg]

I know, but I need something simple enough. It's not easy to reconcile their horrifying usage of dates with the right typing of kotlinx.datetime. I need a single type that can do it all, and in this case it's Instant, as all PHP code we have will expect a full broken iso datetime String anyway.

[Awkin]

For example, it's Monday right now in Samoa: https://www.timeanddate.com/worldclock/samoa/apia
In New York it's Sunday: https://www.timeanddate.com/worldclock/usa/new-york

[Awkin]

So what's the local date of the current moment?

[ribesg]

Yes I know how dates work thanks. Unfortunately I also happen to be the only one in the company it seems.

[Awkin]

What I don't understand I guess is why Greenwhich is the most important time zone using which we decide what date it is now.

[ribesg]

The idea is that the code gives always the same result, env timezone shouldn't matter, that's why I try to enforce UTC everywhere

[ribesg]

If you can only have one timezone UTC is the obvious one, it's the least incorrect

[Awkin]

So you're not actually interested in what date it really is, you want to bucket instants into 24-hour chunks with some predictable borders?

[Awkin]

Though UTC will be close enough to the real date anyway.

[ribesg]

Basically, you can see that as storing a set of numbers. For example, Christmas 2024 is the 25th of December. The timezone does not matter. In this specific case we store dates and times of real events with specific locations, so the date and times are the ones at the location i.e. actual local dates

[ribesg]

We could store the right date with the right timezone every time but that's far too much for the little PHP developers brains 🫠

[Awkin]

Yeah, the only thing I'm confused about is the "date of the *current moment*" part. "Date of Christmas" I do understand, and the "date of the concert in New York" is also clear.

[ribesg]

It's not the current moment, I only use Instant because it can be serialized as anything. We mostly use that "today" thing when initiating stuff with a default value which they chose to be the current UTC day, so I just need to reproduce that "algorithm"

[Awkin]

Got it. My condolences, truly.

[ribesg]

In theory I could store it with any timezone and it should not matter as only year month and day are supposed to be read, in practice this is not what happens.

I regularly hear "it's just a date", they act like it's trivial and doesn't need any second of thinking