If I get a String like for example ```2025-03-24T0...

# kotlinx-datetime

[Stylianos Gakis]

If I get a String like for example

2025-03-24T08:00:00.000001Z

Which indicates that it's in UTC time, hence the Z afaik
But I may get an instant which is not Z there, but some other timezone too

Is there a way for me to turn it into a LocalDateTime, but using whatever time-zone the string itself already came in?

So I want to do

Instant
 .parse("2025-03-24T08:00:00.000001Z")
 .toLocalDateTime(???)

But not sure what I should do for timezone.

The use-case is that my server is giving me a timestamp, and I want to show the date only as-is, so whatever the server had decided already. So if you are in different parts of the world you do not get different results (if I used TimeZone.currentSystemDefault()) but I also don't want to just default to UTC and potentially change the date that I show if the timestamp was not in UTC.

[Dmitry Khalanskiy [JB]]

So, did I get this correctly: for a string like 2025-03-24T08:00:00.000001+03:00 , you want to obtain LocalDateTime(2025, 3, 24, 8, 0, 0, 1000)?

[curioustechizen]

If I understand the question correctly, you don't want to parse an Instant, you want to parse a LocalDateTime instead. But that expects the trailing Z to be absent.

You might be able to still parse it using custom formats (I haven't worked with those so not sure how feasible this is).

[Stylianos Gakis]

If I understand the question correctly, you don't want to parse an Instant, you want to parse a LocalDateTime instead. But that expects the trailing Z to be absent.

Yeah I think this is what I am looking for too, because parsing LocalDateTime fails for me there, because it does not like the Z (or whatever else) to be there

LocalDateTime(2025, 3, 24, 8, 0, 0, 1000)?

Yes, optimally. And I could even do without knowing about the millisecond accuracy, but I suspect that's not the biggest of deals there.

[eygraber]

Welcome to hell (sorry I have no answers, but I do have similar problems 😅).

Whatever solution you come up with will almost always get broken because a backend engineer didn't think using a new format without telling anyone would be a problem.

[kevin.cianfarini]

I think what you’re actually reaching for is a ZonedDateTime as it’s known in Java. This is a long standing open Github issue with kotlinx-datetime.

[kevin.cianfarini]

If you’re only after the LocalDateTime chunk as it’s represented in the ISO string (eg. 2025-03-24T08:00:00.000001 ), then you could do this:

val localDateTime = Instant.parse("2025-03-24T08:00:00.000001Z).toLocalDateTime(TimeZone.UTC)

I think this will work for your use case because Instant will always be normalized to UTC time. The conversion between UTC time and local time with the UTC timezone is a 1:1 mapping.

[eygraber]

The problem is LocalDateTime crashes if there is a Z present and ZonedDateTime crashes if there isn't one.

[kevin.cianfarini]

This should work for other utc offsets other than Z, for example:

val localDateTime = Instant.parse("2025-03-24T08:00:00.000001+03:00).toLocalDateTime(TimeZone.UTC)

Would spit out 2025-03-24T05:00:00.000001 local time.

[kevin.cianfarini]

The problem is LocalDateTime crashes if there is a Z present and ZonedDateTime crashes if there isn’t one.

Based on some of the above comments I’m not sure this is my understanding of the issue. Instead, @Stylianos Gakis wants to grab the local date time representation of an ISO-8601 timezone qualified string

[kevin.cianfarini]

I could be wrong, though!

[eygraber]

Ah you're right, I read that wrong 😅

[Stylianos Gakis]

Yeah, doing toLocalDateTime(TimeZone.UTC) wouldn't work because then I may end up changing the date if the incoming timestamp is not already in UTC.
It may for example be in time zone +5 and have time of 02:00, so if I do this conversion I will go back one day 😅

I basically want the backend to give me whatever date it wants to give me, and use that as what I show on the screen, regardless of where the user may be in the world.

[kevin.cianfarini]

It sounds like the backend should be sending you both an ISO-8601 fully qualified datetime string as well as separately an tzdb identifier. That's what we do.

[Stylianos Gakis]

Yeap, it looks like I need to talk with some colleagues about this in general. Ty for the discussion 🤗

[curioustechizen]

+1 to the server sending both the datetime as well as timezone. Seminal reading for this topic (the kotlinx-datetime docs link to it too): https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/

There was also a presentation from the authors of kotlinx-datetime but I cannot find it right now.

[Dmitry Khalanskiy [JB]]

📣 Here's the correct answer: https://pl.kotl.in/o-bf5hdiI