Is there a bug in DatePicker? It seems to be outputting the date before the date the user picks. Is...

# compose

[Brill]

Is there a bug in DatePicker?
It seems to be outputting the date before the date the user picks.

Is this a known thing?

[Stylianos Gakis]

What do you mean "outputting"

[Brill]

I mean that if the user selects Jan 4th, 2025, the output is Jan 3rd, 2025

[Stylianos Gakis]

The date picker is in utc time without a way to configure it I think.

[Brill]

yes, it uses long timestamp which is always in UTC,

but you should be able to convert it to local to see whats going on, e.g.:

Instant.fromEpochMilliseconds(it).toLocalDateTime(timeZone = TimeZone.currentSystemDefault()).toString()

[Stylianos Gakis]

Yeah this will tell you what time, in your time zone, the utc time of say 00:00 of 27th of February was.

And it may be that in your time zone, that is, say, 22:00 of 26th of February.

[Brill]

I understand the time zones. the picker actually uses the system timezone to do its picking.
so you are picking in the system timezone, and the picker is outputting the date before.

[Stylianos Gakis]

Does it use the system timezone?
When I tried this component it was using utc always. You should probably look into the implementation to see if anything has changed in the current version.

[Brill]

it gives you the result in a timestamp (which is UTC) thats a good thing, means its always consistent, the problem is the timestamp is the day before what the user selects.

[Brill]

long timestamps are always UTC, thats by design, thats why its using them. when it picks it is picking in the users TZ, it needs to do a conversion back to UTC when it outputs... which its doing, but as far as I can tell, its a day behind.

[Stylianos Gakis]

We can verify that by plugging the result you get by picking some date in the picker into somewhere like here https://www.epochconverter.com/

If that's the case, and I am not misunderstanding something, perhaps it's worth filing a bug report?

[Brill]

I am digging now. let me generate some data. The input is irrelevant since the user picks that in the component.

Thinking about it, i seem to remember this problem happening in the old view code as well. I wonder if its operating the same way for backwards compatability.

[Brill]

You are right, its specifically outputting in UTC, I wonder what happens in the edge cases.

to get the correctly picked date you need to do this nonsense:

Instant.fromEpochMilliseconds(it)
.toLocalDateTime(TimeZone.UTC).toInstant(timeZone)

[Brill]

its actually pretty weird because

Clock.System.now()
    .toLocalDateTime(timeZone = timeZone)

returns the correct value. you are feeding that into the date picker and it explicitly converts it to UTC.
it really shouldn't do that (it doesn't need to), but I think thats how the legacy date picker worked as well.

[Stylianos Gakis]

https://issuetracker.google.com/issues/281859606
https://issuetracker.google.com/issues/266202516

Perhaps take a look at these and plus them if you feel that they fit your question here