Folks, we need your feedback! The kotlinx-datetime...

# announcements

[hhariri]

Folks, we need your feedback! The kotlinx-datetime team seeks your thoughts on the format string API for non-localized date/time formats. Share your views and help us build the best API for handling dates and times: https://kotlinlang.slack.com/archives/C01923PC6A0/p1685626036546549

[Oleg Yukhnevich]

I believe it’s better to add direct slack link here, as now if you use slack app it redirects to browser, only to redirect back to app 🙂

[hhariri]

Sorry, you’re absolutely correct. Fixed, thanks.

[Mike Digman]

1️⃣ for me, coming from a Java codebase so the tighter match the better

[Mike Digman]

Not opposed to having multiple formatting options though, especially if there’s a more sane time formatting method that’s been proven elsewhere

[Anonymike]

First off, I'm incredibly excited to see kotlinx-datetime moving forward again! Thank you!

I'm with @Mike Digman here, but totally understand the want to correct for some of these issues. Personally, I think a clean builder API may be best in addition since everytime I make a date formatter I'm usually caching it for a long time or putting it in a instance variable. I'm not a fan of recreating them 1000s of times. I think other formats are interesting but at this point I don't know how quickly the adoption will go just because it will take time.

If it helps some of the most common issues I see with date time formatters (almost every time) are:
1. M (Month) vs m (minute)
2. Optional parts being handled awkwardly. For instance [:mm] doesn't work the same way for 0 minutes as it does with other parts of the date. 9:00AM vs 9am
3. I will often render AM PM and 100% of the time need to lower case it. It is a pain to get javas formatter to do that without specially configuring a format token, so I end up lowercasing the whole string after formatting with a time format like "h:mma".
Between numbers 2 and 3 above we end up with a nasty looking date format code that has formats with/without minutes and a lowercase stuck on it. Happy to share more if it helps, but I feel like these are common friendly formats in the US at least and I can't be the only one running into it. Any solution that improves those kinds of things I'm absolutely open to.

[stantronic]

option 5️⃣ would seem to be a good idea alongside any of the other alternatives, not necessarily mutually exclusive

[darkmoon_uk]

5️⃣ Seems most progressive to me. I suspect most Devs work with Dates and Times regularly, but not frequently enough that we actually remember date/time formats. As such, we're forever going back to 'string format' reference documentation for yet-another-standard.

Designing with a builder-API-first philosophy reduces the need for documentation as the standard becomes baked into the API.

It also doesn't preclude a format string interpreter being layered on top, for the perhaps rarer use-cases where people still need one. As @stantronic says they're not mutually exclusive and can be complementary.

[Hardik Trivedi]

The option 1️⃣ seems a good choice. It's one of the formats which the community has used most. Java people can also adapt it easily, so better reachability that way. Swift also has a similar format option so iOS guys will be happy with that too. A win win option for all of us.