`ColumnRenderer` implementations for java.time types `Instant`, `OffsetDate

Vaadin 8.1 bundles ColumnRenderer implementations to enable Vaadin Grid to display some, but not all, of the java.time types.

Included are:

  • LocalDateRenderer (for java.time.LocalDate objects)
  • LocalDateTimeRenderer (for java.time.LocalDateTime objects

Those are classes puposely have no concept of time zone or
. As such, they have limited usefulness.

Missing are ColumnRenderer implementations for the java.time classes that
have an offset or zone:

So I did some digging and learned how to write my first Vaadin add-on, to provide column renderers for these three types:

  • InstantRenderer
  • OffsetDateTimeRenderer
  • ZonedDateTimeRenderer

And I built a working demo app to show their use in a Vaadin Grid, using Vaadin 8.1.4.

My source code for both the implementations and the demo app is
available on BitBucket in a project named timecolumnrenderers
. Published under Apache 2 license.

➠ Please review! Give me feedback.

The critical part is the encode method at the bottom of each InstantRenderer, OffsetDateTimeRenderer, and ZonedDateTimeRenderer class.

Ideally I would like the Vaadin team to bundle these classes with Vaadin (or provide their own implementation). To that end I copied their published source code for those Local… classes listed above. I used their source code as a base, changing only the minimum needed to work with the other java.time types. I followed their lead on the API. I do not exactly agree with their API, as I think accepting the String object for a formatting pattern as constructor arguments is misguided. Other constructors take a
object. I believe a better design is to always rely on the calling programmer providing a DateTimeFormatter object, and keep the column renderer classes out of the business of building a formatter object internally. But their API is already published in a shipping product (Vaadin 8.1), so I followed along and did the same.

See attached file for screen shot of the demo app.

Nice to see your effort. However you can possibly see, that you are repeating the same pattern, which is essentially date type to String conversion, which you have embedded in Renderer logic.

​I studied the same problem, when I added the ConverterRenderer to my collection. Instead of just thinking about Dates or different types of Number formats, I went more minimalistic, i.e. made Renderer, for which you can give any String conversion as a parameter, thus making it as generic as possible.