3 ms·
Let's imagine that I have a perfectly reasonable looking piece of code in my app: db.write(Event(timestamp=int(datetime.datetime.utcnow().timestamp())) Af
by ak217 3y ago
Let's imagine that I have a perfectly reasonable looking piece of code in my app:
db.write(Event(timestamp=int(datetime.datetime.utcnow().timestamp()))
After the change that you propose, the timestamps written by this code will jump by an amount equal to the offset of the local timezone this machine runs on (and also lose any DST adjustment they might have had).
Now, let's imagine another independent process is consuming events from the database and compares an event written before this change to one written after.
Python is a popular language, used in production by scheduling applications around the world. The potential downside of this kind of change is measured in billions of dollars. The safe solution is of course to not silently change the API in a breaking way, and instead introduce a new API and get someone to look at why the code stopped working.
- wodenokoto 3y agoOn my machine, a naive timestamp from utcnow() and a utc timezone aware datetime object from datetime.now(tz=ZoneInfo('utc')) produces the same timestamp. datetime.now() does not return utc time (but does return a naive datetime object)
- ak217 3y agoOK, but that's not relevant to the scenario that I described.
- wodenokoto 3y agoHow is that not exactly the scenario?