I'm trying to convert some Time and Date to UTC but I get this issue from DateTimeConverter:
AttributeManager: The input datetime '20161106012242' falls inside a daylight savings transition and is ambiguous in the local timezone
AttributeManager: Failed to evaluate expression '@TimeZoneSet(20161106012242,local)'. Result is set to null.
Does anyone know what's going on?
+17
Hi @dta255, when you use 'local' as the destination timezone, the @TimeZoneSet function works with convert mode, and unzoned input will be rejected in convert mode. See the help to learn more.
If the input datetime was a UTC time, this setting should work.
@TimeZoneSet(20161106012242+00:00,local)FME treats it as below.
@TimeZoneSet(20161106012242+00:00,local,convert)Hi @dta255, when you use 'local' as the destination timezone, the @TimeZoneSet function works with convert mode, and unzoned input will be rejected in convert mode. See the help to learn more.
If the input datetime was a UTC time, this setting should work.
@TimeZoneSet(20161106012242+00:00,local)FME treats it as below.
@TimeZoneSet(20161106012242+00:00,local,convert)If the timezone offset for the input datetime is unknown, there is no way to convert it. However, I suppose you know the timezone offset in your locale for the date (month, or month and day) in the datetime. If you know that, you can extract the date from the input datetime and then determine an appropriate timezone offset according to the date.
+9
I don't know if the answer from @Takashi Iijima solved your problem, but there's another explanation for the message which I just encountered myself.
Taking a closer look at the datetime provided in your example (20161106012242), the time part of that is 1:22:42 AM. Daylight savings ended at 2am on November 6th, 2016, and rolled back to 1am. The period between 1am and 2am is what FME calls the "daylight savings transition". FME doesn't know if any unzoned times between 1am and 2am have been rolled back to the transition or are correct as-is. For example, 1:22am could actually be 1:22am (before the rollback) or it could actually be 2:22am (and subsequently rolled back to 1:22am). For Pacific Time, that could be an offset of -08:00 or -7:00, respectively.
I'm not sure what the best way of dealing with this is to be honest - I have thousands of records in various tables that I need to convert to UTC time to support ArcGIS Enterprise/AGOL feature services and dashboards.
+9
I don't know if the answer from @Takashi Iijima solved your problem, but there's another explanation for the message which I just encountered myself.
Taking a closer look at the datetime provided in your example (20161106012242), the time part of that is 1:22:42 AM. Daylight savings ended at 2am on November 6th, 2016, and rolled back to 1am. The period between 1am and 2am is what FME calls the "daylight savings transition". FME doesn't know if any unzoned times between 1am and 2am have been rolled back to the transition or are correct as-is. For example, 1:22am could actually be 1:22am (before the rollback) or it could actually be 2:22am (and subsequently rolled back to 1:22am). For Pacific Time, that could be an offset of -08:00 or -7:00, respectively.
I'm not sure what the best way of dealing with this is to be honest - I have thousands of records in various tables that I need to convert to UTC time to support ArcGIS Enterprise/AGOL feature services and dashboards.
In my particular use case, I knew the data in my database table was at true 1am on the PDT-->PST transition day (November 1st, 2020). So I subtracted an hour from all the timestamps, converted to local timezone, and then added the hour back.
After that I could convert the local timezone datetime values to UTC.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
