Python datetime pitfalls, and what libraries are (not) doing about it
dev.arie.bovenberg.net
Python datetime pitfalls, and what libraries are (not) doing about it
1–10 of 150 posts
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#2I wish such an overview also existed for Go. Yes I could do it but I’m lazy.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#3I don't think any of the DST complaints are legitimate.
If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules.
The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#4I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
As long as you can't predict the future, some future date since a specific cut-off can't be reliably converted to UTC (not GMT, which does observe DST) anyway.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#5ISO 8601 is the only way to go.
With that said, it's hard to control what systems others use. I frequently work with datasets that have 4-5 different timestamp formats.
One of the most annoying bugs I've worked on, was in a table where almost everything followed a DDMMYYYY format - sans a 2-3 month period where the dates were flipped to MMDDYYYY
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#6I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
As long as you can't predict the future, some future date since a specific cut-off can't be reliably converted to UTC (not GMT, which does observe DST) anyway.
GMT does not have DST. It is only slightly different from UTC. That said, you should really use UTC.
I think you are confusing it with British Summer Time which is GMT +1
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#7I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users.
If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#8ISO 8601 is the only way to go. With that said, it's hard to control what systems others use. I frequently work with datasets that have 4-5 different timestamp formats. One of the most annoying bugs I've worked on, was in a table where almost everything followed a DDMMYYYY format - sans a 2-3 month period where the dates were flipped to MMDDYYYY
Does ISO 8601 fix any of the problems mentioned in the article? It doesn't really seem relevant to me.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#9ISO 8601 is the only way to go. With that said, it's hard to control what systems others use. I frequently work with datasets that have 4-5 different timestamp formats. One of the most annoying bugs I've worked on, was in a table where almost everything followed a DDMMYYYY format - sans a 2-3 month period where the dates were flipped to MMDDYYYY
That bug is probably because of someone opening a CSV in Excel.
It's a common one, sadly. Anyone using the US date format for transfer or storage (debatably also display) should consider it a bug.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#10I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
As long as you can't predict the future, some future date since a specific cut-off can't be reliably converted to UTC (not GMT, which does observe DST) anyway.
A true observation, especially since many European countries (or just some citizens) wish to get rid of DST.
However, ±1 hour is not much of an error when talking about a time delay of at least a year.