Some IPFIX exporters avoid this problem by using the newer absolute timestamp fields such as flowStartSeconds(150), flowEndSeconds(151). There are variants for millisecond precision, microsecond precision, and so on. See:
http://www.iana.org/assignments/ipfix/ipfix.xhtml
(Also, note that the absolute timestamp in the IPFIX header is supposed to be close to when the packet was actually completed and sent, so you at least have a shot at modeling the clock offset between the exporter and your collector:
https://www.rfc-editor.org/rfc/rfc7011#page-14)
But as you point out, a problem arises when an IPFIX exporter sends the legacy fields flowEndSysUpTime(21) and flowStartSysUpTime(22). That was OK for NetFlow v1-9 because the header timestamp was expressed in sysUpTimeSeconds too, but with IPFIX it leaves you stranded.
One simple solution is to assume that flows are always flushed promptly, calculate their duration, and line them up with NOW:
duration = flowEndSysUpTime - flowStartSysUpTime
start = (NOW - duration)
end = NOW
Another approach is to assume that at least some flows are flushed promptly, and maintain an estimate for each device boot-time using the flowEndSysUpTime numbers:
boot-time = MIN(NOW - flowEndSysUpTime)
start = boot-time + flowStartSysUpTime
end = boot-time + flowEndSysUpTime
but then you have to be careful to detect a step change in your estimate for boot-time if the device is actually rebooted. And that step change might only be ~30 seconds if it was rebooted twice in quick succession. Something to think about -- but since these legacy fields are only accurate to 1 second it's not clear that being clever is worth the trouble.
