LocalDates

[Quafadas]

I'm searching for guidance on what "best practise" for "LocalDate" might be.

I have a use case, where the most granular time unit I care about is a day. I'm not really worried about timezones.

I'd prefer my case classes to reference LocalDate as opposed to timestamp if I can - because it shaves off a lot of mental overhead. I recongise this is a niche usecase - am guessing this won't be like that time I blindly hit on first class support for UUIDs :-)...

I can think of a couple of ways of managing this... but I'm wondering if there's an ideal one I'm missing.

1. Encode as timestamp. Have some helper functions which move between LocalDates <-> timestamp by discarding the extraneous parts.
2. Have smithy transport the dates as strings, constrain the strings via a regex pattern (simplistically) "^\d{4}-\d{2}-\d{2}$".

I can think of disadvantages to both of these... which I'm happy to delineate, but guessing you already see them.

Before I go off and shoot myself in the foot, is there an obviously better solution you'd be willing to hint at ?

[Baccata]

Hey @Quafadas,

First a fall, a massive thank you for asking your extremely relevant questions in discussions in github discussion. I've linked your questions time and again to people asking similar questions.

So, unfortunately, Option 2 is gonna be the best practice at this point in time.

We have however started thinking about the (very common) problem of users wanting to get support for custom types, and have some ideas.

[Baccata]

It's also worth noting that on JVM, you have access to a method on Timestamp that convert to OffsetDateTime. It's JVM only because we do not want to impose the (large) scala-java-time dependency on JS users. We might however offer an opt-in "compat" artifact in the future that would provide those same transformations in JS-land.

You could go from Timestamp to OffsetDateTime to LocalTime easily, but that would indeed pollute your API by requiring the callers to provide more than required.

https://github.com/disneystreaming/smithy4s/blob/main/modules/core/src-jvm/smithy4s/TimestampPlatform.scala#L26

[Quafadas]

Many thanks again for the details reply. I'm having lots of fun with smithy4s :-).

[Baccata]

@Quafadas a little update : we've just released version 0.15.0, which adds this feature, which you could now use to solve this. Have fun 😄 .

[Quafadas]

Thanks... I am! I'll have a look tomorrow (I hope!)

[Quafadas]

I finally got around to looking at this properly, and it works great. In case someone else comes across this answer; the link changed from above to;
https://disneystreaming.github.io/smithy4s/docs/codegen/customisation/refinements

Specifically for LocalDate

In a smithy file

use smithy4s.meta#refinement
use ils.smithy#MatlabDateFormat

@trait(selector: "string")
structure MatlabDateFormat {}

@MatlabDateFormat
string LocalDateM

apply ils.smithy#MatlabDateFormat @refinement(
  targetType: "java.time.LocalDate",
  providerImport: "ils.localdate.LocalDateParsers._"
)

package ils.localdate
object LocalDateParsers {

  lazy val fmt = DateTimeFormatter.ISO_LOCAL_DATE

  implicit val provider : smithy4s.RefinementProvider[MatlabDateFormat, String, LocalDate] = Refinement.drivenBy[MatlabDateFormat](
    (s: String) => 
        Try{
            val discardAfterSpace = s.substring(0, s.indexOf(" "));
            LocalDate.parse(discardAfterSpace, DateTimeFormatter.ofPattern("dd/MM/yyyy"))
        }.toEither.swap.map(_.toString).swap,
    (e: LocalDate) => e.format(fmt)
  )

}

[Baccata]

that double swap call can be replaced by .left.map