Two options that I would at least consider:
- One method that takes an
Object
argument. Inside the method do a long chain of if
-else
using instanceof
to find the right type. If you want to support the java.sql
types that extend java.util.Date
(an awful hack), remember to test for those first because instanceof java.util.Date
will also be true. Down side: Your user will not get a compile-time error for passing an unsupported type and may find it difficult to find out why your method throws an exception given a String
or an Integer
, for example (which may represent dates too).
- An overloaded method for each supported type, as @MarkB suggested in a comment. Down side: You need to modify your API for each new supported type added.
Whether you choose one option or the other, convert whatever you get to something that implements TemporalAccessor
and pass it to DateTimeFormatter.format()
.
Just mentioned as a curiosity, String.format()
already implements some of the functionality you envision. It handles TemporalAccessor
, Calendar
, Date
and Long
.