Date Formatter to handle milliseconds

I agree, I've had the same need.

For what it's worth, I ended up solving it using Python.

I agree too and would 'enhance' the Topic.

a Date/Time Format with fractional second is needed and should applicable to all transformers which are using Date-Formats (TimeStamper, DateFormatter ...).

Oracle's TIME and TIMESTAMP Datatype is defined by

TIME [(fractional_second_precision)]

I've got to Import CSV-Data with Informations like "17Jul1990:11:22:33.4567", driven trough the DateFormatter with 'Source Date Format' = "%d%b%Y:%T" and

'Destination Date Format' = "%Y%m%d%H%M%S" Ends up with, suprise suprise,

"19900717112233". The fractional seconds are lost!

You've got extract them before going through DateFormatter, and You have to do this for each Time-attribut of the Feature. The DateFormatter can convert all of them in one transformer, the fractional-handling has to be done for each Attribut on it's own ..

I support this idea. I am current facing the same issue downloading the data from arcgisonline which stores its time/date in Epoch milliseconds.

Here is a workspace to deal with epoch milliseconds until this idea is implemented.

Actually, this is not quite the answer as the sub second precision will be lost if I understand the comments here correctly.

Hi @dr_ysg

I am very happy to announce that FME 2017 supports fractional seconds (up to 9 decimal places). The new DateTimeFormatter transformer will be implemented in FME 2017.1. In 2017.0, please use datetime functions (see Text Editor > Date/Time Functions). For example, to convert seconds from epoch into human friendly temporal value:

or

Fractional seconds will be preserved in all datetime operations in FME 2017. We are now testing Readers and Writers to make sure they have no issues with reading/writing.

Please don't use the old DateFormatter though, as it will still drop the fractional part. DateFormatter will be deprecated as soon as we have DateTimeFormatter ready.

'