Time shift

Not really, you can calculate the years, days, minutes etc, add them to Jan 1 1970 00:00:00.000000. There is no need for any timezone. It is universal time. That is kind of the point of UTC. That is why seconds from epoch time is a good date representation.

You have missed the point. The Python datatype follows a human readable format: year, month, day, hour, minute, second, microsecond, tzinfo.

You are telling me datetime.now() populates, year, month, day,... appropriately for the current unix time and value of TZ. I'm telling you, it does not populate tzinfo. That is, it creates a python naive date. A datetime only valid in the context of the current timezone.

The value this datetime object holds is ambiguous, dependent upon how a programmer interprets it.

One can use appropriate, factory objects, conversion methods, string formatters. The difficulty is that it is a programming convention, a coding style. A programmer unfamiliar with the convention can mess up. They can create a naive datetime that is a local time when it should be a UTC value. Or they can misinterpret datetimes from different timezones. They can use now() which implicitly uses a timezone, but doesn't record that it has done so.

I think this is what utcnow() is for, this convention where naive datetimes are UTC.

I don't know what C standard library date functions are, but python datetime is more than a wrapper, maybe it is a conceptual copy of the C implementation

I've never worked with a company that didn't have its own datetime library.

Interesting: My experience is the exact opposite: The first part of my working life was spent writing COBOL where you have little choice in getting hlold of the date and.or time: ACCEPTing them from the OS returned DDMMYY until CODASYL eventually got round to adding two more digits for the century.

Apart from that, I mostly wrote ANSI C and we never saw any reason to use anything other than the standard C library date&time functions regardless of what countries the code would be running in.

Banking/finance apps are highly dependent on holiday calendars and day count conventions.

Indeed they are: been there, done that and multi-currency systems that are also networked across time zones and national borders are 'interesting' (ever looked into predicting the length of future years in the Islamic calendar (you can't!). However I was more concerned with the sorts of financial networks that run on fault tolerant systems and with ATM networks than with financial institution's internal systems.