Hi,

 

 

I suspect you have a time zone definition on your DATETIME field that is somehow picked up by FME without being shown. There is otherwise no way for FME to know that your input date is in the UTC time zone and to correct for it.

 

 

If I create a new attribute in FME with the input value:

 

2014-03-29 01:15:00

 

it is correctly formatted to 

 

20140329011500

 

 

However, if I change the input attribute to:

 

2014-03-29 01:15:00 UTC

 

the formatted output is (with automatic format detection)

 

20140329021500

 

Just as you observe, FME automatically converts to the local time zone (which is CET for me).

 

 

On the other hand, you have a typo on the source date format, it should be:

 

%Y-%m-%d %H:%M:%S

 

 

Try making a temporary copy of the DATETIME attribute and pass that through the DateFormatter instead and let us know how it works.

 

 

Alternatively, you'll have much more fine grained control over these operations if you use a PythonCaller and the datetime (https://docs.python.org/2/library/datetime.html) module.

 

 

David

---

Thanks for the reply.

 

 

The input data is plain text so there is no time zone definition.  I have tried adding the time zone to the input using stringConcatenator but that doesn't help because I think the problem is that the DateFormatter seems to output in the local timezone and there's no apparent method of controlling that.

 

 

I tried copying the attribute but that made no difference.  I guess it's time to look at alternatives to the DateFormatter.

 

 

Thanks again

 

 

(ps the typo was in the question but the workbench was correct)

---

Hi,

 

 

that is strange. As you can see above, I tested the same values as you and got a properly formatted date without any time zone adjustments.

 

 

You say that the input data is plain text, is it CSV or something like that? Could you paste some of your input data here?

 

 

David

---

Hi David

 

 

It's going to be difficult to include a sample of the data because it's quite complicated and difficult to untangle it from all the other transformations that are going on.  However I've created a simple workbench and sample data (csv) that replicate exactly the problem I'm having.

 

 

The results are weird and are shown below:

 

 

The original date is in col1 and the formatted date is in col2.

 

 

At 00:00 on 2014-03-30 (the date daylight savings started in the UK), the datetime has been formatted correctly.  At 01:00 the dateformatter sets the time back an hour.  At 02:00 everything is normal again.

 

 

I've been through my data and this is only happening on 2013-03-30 between 01:00 and 01:59

 

 

Here's the workbench if you want to try it out:

 

workbench (http://eidchub.ceh.ac.uk/administration-folder/tools/folder.2014-04-04.2458888197/dateformatter.fmw)

 

input data (http://eidchub.ceh.ac.uk/administration-folder/tools/folder.2014-04-04.2458888197/dataSample.csv)

 

---

Hi,

 

 

I agree with you, this looks like a bug in FME. I highly suggest you report it to Safe support.

 

 

Meanwhile, here is a script for a PythonCaller that will do the same thing:

 

 

---

 

import fmeobjects

 

from datetime import datetime

 

 

def FormatDate(feature):

 

    try:

 

        input = feature.getAttribute('DATETIME')

 

        formatted = datetime.strptime(input,'%Y-%m-%d %H:%M').strftime('%Y%m%d%H%M%S')

 

        feature.setAttribute('DATETIME', formatted)

 

    except:

 

        pass

 

---

 

 

 

 

Attention: it will silently ignore all DATETIME values that cannot be parsed according to the input mask.

 

 

David

---

2013-03-30 is the day we switch back to DST, which means that from 01:00 we go directly to 02:00, which is the same time frame your four dates are going wrong. You could argue that the four datetimes you are trying to convert don't exist. I'm afraid I don't have a solution or a workaround, I just wouldn't be surprised if there was a bug for those dates in FME.

 

 

One thing that does surprise me: at 2:00 the time converts correctly again. My very rough guess would be that the datelibrary FME uses can do the conversion correctly (as all the other dates convert correctly), but it doesn't know how to handle the non-existent dates.

---

Great catch on the DST switch date. I definitely think you're on to something.

 

 

This info might be well worth to include in a report to Safe.

 

 

David

---

Thanks so much for all your help

---