A quick question: is there an appetite for a Swift...

# kotlinx-datetime

[Dmitry Khalanskiy [JB]]

A quick question: is there an appetite for a Swift-style datetime formatting API where the format is defined directly in the format invocation, like

val dateTime = LocalDate(2026, 5, 28).atTime(19, 58)
dateTime.format { monthNumber(); char(' '); day(); char(' '); time(LocalTime.Formats.ISO) }

Currently, you have to allocate a format in a separate object and then use it:

val dateTime = LocalDate(2026, 5, 28).atTime(19, 58)
val myFormat = LocalDateTime.Format { monthNumber(); char(' '); day(); char(' '); time(LocalTime.Formats.ISO) }
dateTime.format(myFormat)

This has the benefit of guiding programmers to store the format in some field once and use it multiple times (which amortizes the construction costs).
However, when called only once, the first form could actually be more performant, and it's also more succinct.

[CLOVIS]

How much of a performance impact would it be?

I personally would use such an overload if it was available, because it feels more discoverable and more convenient, but I understand the intent of encouraging users to keep the instance around.

[hfhbd]

I really like the format instance to be forced to „document“ the date format like val germanDateFormat = …

[Thomas Hormes]

While I agree with @hfhbd I also think there's also value in having the format invocation variant.

[El Anthony]

I also like the instance format. Using it only once doesn't have a significant performance penalty. If you use it more than once, it's already created. And I have it defined in a simple utility class that I copy from one project to another.

[Dmitry Khalanskiy [JB]]

The exact performance impact is difficult to estimate now, because the current implementation isn't optimized. I believe the current format calls could realistically become twice as fast as they are now. We're focusing on stabilizing the library at the moment, getting the APIs right, and once we do, we'll dive into optimization, using what we have now as a reference implementation whose behavior we should match.

Currently, a naive implementation of dateTime.format { something() } is actually faster than using a pre-allocated structure, because it gets to sidestep the entire naively written parsing/formatting machinery!

From staring at the profiler and meditating on which complexity is inherent and which is avoidable, my current guess for the result we'll eventually see is:
• Allocating a new format for use in formatting (without ever calling parse) is 3 units of time,
• Formatting with a preallocated format is 1 unit of time,
• Formatting with an inline format is 1.3 units of time.
In any case, I'm certain the difference wouldn't be an order of magnitude or even close to that.

The question is mostly about whether the API would look nice, in your opinion. Right now, the impression is that there isn't all that much interest and the API is a "nice-to-have" at best.

[Anonymike]

In some projects we have lazy properties on an object for Formatter, Fonts, etc. that we need to load and we'll also do some more dynamic "caching" delegates like val myDateFormat by dateFormat("format here"). An language we used to use called CFML (ColdFusion) had a lot of conveniences like this and under the hood it would cache objects, etc. While it was tailored for more productive development, it balanced many things well between convenience and optimization regardless of the judgment some gave it haha.