# announcements


06/06/2023, 8:22 AM
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:
👍🏻 1
1️⃣ 10
2️⃣ 4
5️⃣ 3
🙏 5
👀 1
👍 26
👍🏼 1
3️⃣ 2
K 19

Oleg Yukhnevich

06/06/2023, 8:24 AM
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 🙂


06/06/2023, 8:24 AM
Sorry, you’re absolutely correct. Fixed, thanks.
👍 1

Mike Digman

06/22/2023, 6:12 PM
1️⃣ for me, coming from a Java codebase so the tighter match the better
Not opposed to having multiple formatting options though, especially if there’s a more sane time formatting method that’s been proven elsewhere


06/27/2023, 3:21 PM
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.


06/30/2023, 12:43 PM
option 5️⃣ would seem to be a good idea alongside any of the other alternatives, not necessarily mutually exclusive
👍 1


07/03/2023, 12:40 AM
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

07/04/2023, 6:18 AM
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.