What is the standard terminology for dates in FME
From Fmepedia
| Table of contents |
Q) What is the standard terminology for dates in FME?
A) The standard terminology for dates (and times) in FME is...
yyyymmddhhmmss.xxx(+/-)xx
Where...
- yyyy is the year in 4 digits, eg 2006
- mm is the month number, eg 07 for July
- dd is the day of the month, eg 21
- hh is the hour (24 hour clock I believe - eg 14 for 2pm)
- mm is the number of minutes
- ss is the number of seconds
- .xxx is the number of milliseconds
- (+/-)xx is the timezone (compared to GMT I think, so -08 is Pacific Time Zone PST)
For example, the time I'm writing this (08:37:10, 8 Sep 2006 (PDT)) is...
20060908083710.000-08
That isn't to say that yyyymmddhhmmss.xxx(+/-)xx is a standard format for dates to be supplied by FME. When creating your own dates it is acceptable to use any combination of the above, and when dates are returned by a reader the format will depend on what is stored and supplied by the format itself.
For example, it is permitted to simply use...
yyyymmdd
...as a date definition, giving...
20060908
Q) What FME Readers/Writers support timezones?
A) Currently, no FME Readers/Writers support timezones, even though the actual format itself may support them.
Q) What transformers rely on the correct date format?
A) The DateFormatter and the AttributeClassifier.
Q) I'm developing a format reader using the plug-in SDK - will FME automatically convert my dates to this format?
A) FME will not do anything to your dates - even if you read them as type fme_date. The structure will be unaltered.
However, when a workspace is created and your attribute maps with a writer attribute type fme_date then there is the risk it would not get written correctly.
If you are able, converting your dates to the FME format is preferable. If you wish to keep the original date structure then assign it to a string attribute rather than a date.
