hehe, that's no fun at all. Although, let's be clear this is quite clearly a python issue not FME. Python should be able to handle this.

But I have actually be after a reliable way to reduce the precision of the seconds for other reasons. I've actually defaulted to converting everything to %s in FME. (seconds from epoc in UTC (or %Es if unzoned)).

In Python you can also just add the number of seconds to the origin time and get what you want. There isn't the issue with precision.

import fme
import fmeobjects
import datetime
from datetime import datetime, timedelta, timezone
 
 
    def input(self, feature):
        timestamp=feature.getAttribute('_timestamp')
        print(timestamp) #1687356496.1503231
        
        pytime=datetime(1970,1,1,tzinfo=timezone.utc) + timedelta(seconds=float(timestamp))
        print(pytime) #2023-06-21 14:08:16.150323+00:00
        self.pyoutput(feature)

There is probably still a better way but this is at least workable. Unfortunately this means you have to either keep track if the data is zoned or unzoned as it's not kept in the attribute (but you don't need to know the specific timezone). 

import fme
import fmeobjects
import datetime
from datetime import datetime, timedelta, timezone
 
 
    def input(self, feature):
        timestamp=feature.getAttribute('_timestamp')
        print(timestamp) #1687356496.1503231
        
        pytime=datetime(1970,1,1,tzinfo=timezone.utc) + timedelta(seconds=float(timestamp))
        print(pytime) #2023-06-21 14:08:16.150323+00:00
        self.pyoutput(feature)

> Although, let's be clear this is quite clearly a python issue not FME. Python should be able to handle this.

The precision issue, sure, but I'd still say fmeobjects should be able to handle datetime marshalling automatically.

> But I have actually be after a reliable way to reduce the precision of the seconds for other reasons. I've actually defaulted to converting everything to %s in FME. (seconds from epoc in UTC (or %Es if unzoned)).

That's actually a pretty good idea, though with the caveats that you're raising regarding loss of timezone information, plus how dates become unreadable in the feature inspector when you do that, plus how you would still need to convert them back to dates before writing them in a database or something.

It's an interesting workaround, though, and I'll be sure to keep it in mind.

> pytime=datetime(1970,1,1,tzinfo=timezone.utc) + timedelta(seconds=float(timestamp))

FYI, you can use datetime.utcfromtimestamp(timestamp).

Ok, so, as I found out going through the SDK doc and letting Pycharm generate .pyc function list stubs for me, there is a correct way to do this.

import fmegeneral.fmeutil as fmeutil
 
py_datetime = fmeutil.fmeDateToPython(fme_datetime)
 
# fme_datetime: "20230724152232.3451145+00:00"
# py_datetime: (datetime.datetime(2023, 7, 24, 15, 22, 32, 345114, tzinfo=<fmegeneral.fmeutil.FMETZInfo object at 0x000000000EB8E010>), True, True)

That's it. I've not seen it documented anywhere, I've not seen it mentionned in these forums even once. It handles decimal rounding, timezone offsets (using its own FMETZInfo offset object), detecting whether you're parsing days or naive datetimes or timestamps, everything! It's right there and it does everything as one would expect it to, so why is it that nobody seems to know about this?

Issue solved. Hopefully that will give some visibility to this fmeDateToPython function.

EDIT: Other useful functions in there include:

• isoTimestampToFMEFormat(isoTimestamp)
• pythonDateTimeToFMEFormat(theDateTime)

import fmegeneral.fmeutil as fmeutil
 
py_datetime = fmeutil.fmeDateToPython(fme_datetime)
 
# fme_datetime: "20230724152232.3451145+00:00"
# py_datetime: (datetime.datetime(2023, 7, 24, 15, 22, 32, 345114, tzinfo=<fmegeneral.fmeutil.FMETZInfo object at 0x000000000EB8E010>), True, True)

Thanks for sharing this. I'll have to see what other stuff is in fmegeneral. Interesting, I've personally not looked into the SDK but these kinds of functions look pretty helpful. 

As it turns out, the source for fmegeneral used to be in the repository for fmetools, so you can seill see what the actual, commented and documented code looks like and how each function works or not.

However, most of these are somewhat flawed. PythonDatetimeToFmeFormat can only encode datetimes (not date or time objects) and fails when tzinfo is not an instance of FMETZInfo. fmeDateToPython is more reliable, but the RegEx they use doesn't match their own datetime format specification ("20230303.123456" is valid but "20230303101010-0430" fails to capture the offset properly and the offset is registered as "-04:00").

Still, it's definitely better and generally more reliable than anything I would have written with strptime.

Their regex should probably read more like this, though:

^(?P<date>\d{8})?(?:(?P<time>\d{6})(?:\.(?P<us>\d+))?(?:(?P<tzs>h\-+])(?P<tzh>d01]o0-9])(?::?(?P<tzm><0-5]p0-9]))?)?)?$