Timezone-naive datetimes are one of the most dangerous objects in Python
Date and time handling in Python can be tricky, especially with timezones and epoch timestamps. Not specifying a timezone when using `datetime.datetime.fromtimestamp()` can lead to errors. It's crucial to attach timezones to datetime objects for accuracy.
Read original article
Date and time handling in Python can be tricky, especially when dealing with timezones and epoch timestamps. The article highlights a common trap when using the `datetime.datetime.fromtimestamp()` function without specifying the timezone (`tz`) argument. If the timezone is not specified, the timestamp is converted to the local date and time of the platform where the code is executed, resulting in a timezone-naive datetime object. This can lead to errors, especially when working with epoch timestamps, which are timezone-independent by nature. To avoid this issue, it is recommended to always attach a timezone to datetime objects that don't have one explicitly defined. By doing so, developers can prevent ambiguity and focus on other challenges related to timezones and datetime calculations. The article emphasizes the importance of understanding timezone awareness in datetime objects to ensure accurate date and time manipulations.
Related
Y292B Bug
The Y292B bug is a potential timekeeping issue in Unix systems due to a rollover in the year 292,277,026,596. Solutions involve using dynamic languages or GNU Multiple Precision Arithmetic Library in C, emphasizing the need for kernel-level fixes.
Python Modern Practices
Python development best practices involve using tools like mise or pyenv for multiple versions, latest Python version, pipx for app running. Project tips include src layout, pyproject.toml, virtual environments, Black, flake8, pytest, wheel, type hinting, f-strings, datetime, enum, Named Tuples, data classes, breakpoint(), logging, TOML config for efficiency and maintainability.
All I want for Christmas is a negative leap second
The author explores leap seconds, discussing the potential for a negative leap second due to Earth's rotation changes. They argue against abolishing leap seconds, emphasizing the rarity and complexity of a negative leap second.
A Relativistic Framework to Establish Coordinate Time on the Moon and Beyond
The paper discusses establishing a coordinate time framework for celestial bodies like the Moon based on Einstein's theory of relativity. It highlights the importance of synchronized clocks for accurate communication and navigation.
Time Travel with Python
The blog post discusses testing time-based functionality in software development, emphasizing the importance of accurate time-based tests for applications across time zones and daylight-saving changes. It introduces Python testing methods using unittest.mock and Freezegun for robust time manipulation.
9 commentsA good general rule of thumb is that for things that happened in the past, UTC is generally fine. You only need a timezone if there was some kind of locality to the event (e.g.: when _and_ where this happened), but usually you can convert to local time. So storing UTC time is fine, adding the timezone in rare cases.
For things that are scheduled in the future, usually you will want to store local time + a timezone identifier (in olsen format, not offsets), to guard against timezone/dst changes (yes they happen all the time)
There are exceptions to rule, but at least in my case 90% of the times I work with are timestamps in UTC and 9.99% things that happen in the future where I can apply the localtime + tz rule.
But yes there are exceptions:
* Alarm clocks (if you set an alarm at 8am, you typically don't want this to shift when you travel). This is called floating time * If you need records of when something was originally scheduled vs when it actually happened if a timezone change occurred. * If you need to handle the awkward DST time change where every time between 1 and 2am happen twice.
Er, not really. Not meaningfully. They can be freely compared with timezone-aware timestamps. They cannot be freely compared with time zone-naive timestamps.
“Timezone naive” is a distinction that applies to datetime objects. It just doesn’t apply to epoch time. The problem with naive timestamps is that you have to somehow remember what the correct time zone is. You don’t have to remember that for epoch time.
The reason you want timezone-aware datetime objects is because you can safely and unambiguously convert them to, say, epoch time.
Today I never use a date without Arrow, no matter how simple the operation is. I am an amateur dev so there maybe performance or portability reasons that make it a bad idea for professional devs, but, man, how easier my life is.
I looked for similar modules in TS (found them) and Go (did not find anything)
Because there's not means people are always dragging in timezone libs or dealing with the consequences.
IMHO, the initialization of a timezone-free datetime should ideally emit a warning in Python.
Related
Y292B Bug
The Y292B bug is a potential timekeeping issue in Unix systems due to a rollover in the year 292,277,026,596. Solutions involve using dynamic languages or GNU Multiple Precision Arithmetic Library in C, emphasizing the need for kernel-level fixes.
Python Modern Practices
Python development best practices involve using tools like mise or pyenv for multiple versions, latest Python version, pipx for app running. Project tips include src layout, pyproject.toml, virtual environments, Black, flake8, pytest, wheel, type hinting, f-strings, datetime, enum, Named Tuples, data classes, breakpoint(), logging, TOML config for efficiency and maintainability.
All I want for Christmas is a negative leap second
The author explores leap seconds, discussing the potential for a negative leap second due to Earth's rotation changes. They argue against abolishing leap seconds, emphasizing the rarity and complexity of a negative leap second.
A Relativistic Framework to Establish Coordinate Time on the Moon and Beyond
The paper discusses establishing a coordinate time framework for celestial bodies like the Moon based on Einstein's theory of relativity. It highlights the importance of synchronized clocks for accurate communication and navigation.
Time Travel with Python
The blog post discusses testing time-based functionality in software development, emphasizing the importance of accurate time-based tests for applications across time zones and daylight-saving changes. It introduces Python testing methods using unittest.mock and Freezegun for robust time manipulation.