Solved

Epoch time is out if range

B
Badge

I am using FME 2018.1 32-bit and while reading an .accdb file, I am encountering this error "WARN |Microsoft Access Reader: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds". Translation stops after this with a Fatal Error message. There are more than 2.5 million records in the table i am accessing. If I give a where condition an extract 100 odd records, it does execute. When i run the same Workbench in FME 2017.0 32-bit without any WHERE condition, it executes successfully. Any info on how can i troubleshoot this error ?

icon

Best answer by chrisatsafe 14 March 2019, 17:01

View original

15 replies

nielsgerrits
Rank
Userlevel 6
Badge +32

No .ffs file with the specific features next to the .fmw file after a fatal error?

chrisatsafe
Rank
Badge +2

Hi @bb,

 

Are you able to re-run the workspace with debugging turned on (Tools > FME Options > Translation > Log Message Filter > Select Log Debug). After running the workspace with debugging on, can you please upload the translation log?

It's tough to say without seeing the log first, but this may be related to a similar issue that is currently being looked into where the translation in FME 2018.1 is failing due to a bad feature or invalid date being read in from an Access Database. This is likely why you are able to read the first 100 features (other tables are likely unaffected by this).

B
Badge

Hi @bb,

 

Are you able to re-run the workspace with debugging turned on (Tools > FME Options > Translation > Log Message Filter > Select Log Debug). After running the workspace with debugging on, can you please upload the translation log?

It's tough to say without seeing the log first, but this may be related to a similar issue that is currently being looked into where the translation in FME 2018.1 is failing due to a bad feature or invalid date being read in from an Access Database. This is likely why you are able to read the first 100 features (other tables are likely unaffected by this).

Find attached the Log file generated in the Debug method as suggested test.zip

chrisatsafe
Rank
Badge +2

Find attached the Log file generated in the Debug method as suggested test.zip

Hi @bb,

Thank you for providing that!

It appears you have come across the same issue that is currently being worked on (FMEENGINE-59331). I will be sure to update this post as soon as the fix is available for download; however, if you would also like to be notified by email, please let me know so I can create a case on your behalf and add you to the contact list for this.

In the meantime, it is recommended to run this workspace in FME 2017.0.

 

Note: if you need to run the translation in FME 2018.1, the Microsoft Access (JDBC) Reader will work as it is not impacted by this issue; however, the jdbc reader will not read features in as fast as the Microsoft Access reader.
B
Badge

Hi @bb,

Thank you for providing that!

It appears you have come across the same issue that is currently being worked on (FMEENGINE-59331). I will be sure to update this post as soon as the fix is available for download; however, if you would also like to be notified by email, please let me know so I can create a case on your behalf and add you to the contact list for this.

In the meantime, it is recommended to run this workspace in FME 2017.0.

 

Note: if you need to run the translation in FME 2018.1, the Microsoft Access (JDBC) Reader will work as it is not impacted by this issue; however, the jdbc reader will not read features in as fast as the Microsoft Access reader.

Thanks @chrisatsafe I will execute the Workbench in 2017. Will wait to hear from you on this issue, once it is resolved. Thanks once again.

chrisatsafe
Rank
Badge +2

Hi @bb,

I’m pleased to let you know that a recent update to FME has resolved this issue!

 

 

You will find the update in the latest FME 2019.0 build (19238+) which is available on the Downloads Page. This update is also available on our Past Downloads Page for FME 2018.1 (build 18592+).

 

 

Thank you for your patience as we worked to resolve this issue. We appreciate your involvement in helping us make FME even better!
fmeuser_gc
Rank
Badge +6

Hi @chrisatsafe,

This is to inform you that I still see the same error in 2019.2 (Build 19801) when tried to convert from Epoch(in milliseconds) to ISODateTime using DateTimeConverter.

J

Hi @bb,

I’m pleased to let you know that a recent update to FME has resolved this issue!

 

 

You will find the update in the latest FME 2019.0 build (19238+) which is available on the Downloads Page. This update is also available on our Past Downloads Page for FME 2018.1 (build 18592+).

 

 

Thank you for your patience as we worked to resolve this issue. We appreciate your involvement in helping us make FME even better!

@chrisatsafe, I am experiencing the same issue as @fmeuser_gc in the comment above. I am running 2019.2 and receive the following error: DateTimeConverter: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds

ebygomm
Rank
Userlevel 1
Badge +10

@chrisatsafe, I am experiencing the same issue as @fmeuser_gc in the comment above. I am running 2019.2 and receive the following error: DateTimeConverter: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds

Is your epoch time in seconds not milliseconds? Often it would be provided as milliseconds so it is necessary to divide by 1000 prior to conversion in FME

J

Is your epoch time in seconds not milliseconds? Often it would be provided as milliseconds so it is necessary to divide by 1000 prior to conversion in FME

My time is provided in milliseconds from ArcGIS Online, so this is a common format. The workaround is to divide by 1,000, although I would like to see this fixed for future users who will see this error and for simplification of workflow.

ebygomm
Rank
Userlevel 1
Badge +10

My time is provided in milliseconds from ArcGIS Online, so this is a common format. The workaround is to divide by 1,000, although I would like to see this fixed for future users who will see this error and for simplification of workflow.

Probably something to suggest as an idea in that case

J

Probably something to suggest as an idea in that case

I was commenting because @chrisatsafe mentioned that this was fixed in 2019.0. Perhaps I misunderstood, but from my perspective, it appears that the transformer may have a bug that does not recognize milliseconds and it appears he is already familiar with this issue.

chrisatsafe
Rank
Badge +2

I was commenting because @chrisatsafe mentioned that this was fixed in 2019.0. Perhaps I misunderstood, but from my perspective, it appears that the transformer may have a bug that does not recognize milliseconds and it appears he is already familiar with this issue.

Thanks for the follow up @jasonschroeder. Are you able to share your log/workspace? If so, please file a case so we can further investigate this issue and reference FMEENGINE-59331 so we can compare the error that you are seeing with the resolved issue. It's possible that this may be a separate (but similar) issue.

J

Thanks for the follow up @jasonschroeder. Are you able to share your log/workspace? If so, please file a case so we can further investigate this issue and reference FMEENGINE-59331 so we can compare the error that you are seeing with the resolved issue. It's possible that this may be a separate (but similar) issue.

@chrisatsafe, thank you. I submitted case:

C154918
M
Badge +2

The FME format flags are derived from a blend of flags used for date formatting in various languages, mostly C++, TCL and Python. Epoch seconds are consistently represented as %s.

Reply


Community Stats

28,670
Posts
109,366
Replies
36,531
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.