3 ms·

> You can make some very bad mistakes in python with dates because they silently coerce into each other in nonsensical ways The Big Problem in Python's datetim

> You can make some very bad mistakes in python with dates because they silently coerce into each other in nonsensical ways The Big Problem in Python's datetime library is the naive/tzaware thing. The same type is used for two very different concepts.

xapata 6y ago
You get type errors if you try to combine two values with different timezones. I think of naive as a null timezone and it makes sense to me. Why is it so different?
- alanfranz 6y ago
  > You get type errors if you try to combine two values with different timezones. What kind of type errors? Maybe you mean naive and tzaware objects? Working on two tzaware objects with different offsets should not yield any error. Otherwise, it's worse than I thought. > null timezone What is a null timezone? Can you make an example of how it would be used in the real world? If you want something for a point in time, you need an attached offset. That's an Instant in java.time. If you need something more "human", then you get a LocalDateTime (in java.time parlance). Which is not a point in time unless you attach an offset to it, or localize it through a timezone. Some operations just don't make sense between LocalDateTime. Example: can you measure the number of hours between one localdatetime and another localdatetime (or even an instant) ? No; because you don't know either offset. Python doesn't prevent such operations; it tries to make things work in a simpler, but wrong way. Date/time handling is one of the hard things to get always right in software engineering; simplification doesn't work.
  - xapata 6y ago
    > tries to make things work in a simpler, but wrong way To be fair, it is an old language. Before Python 3, it used the old assumptions about text being just 1-byte characters. We all know how much trouble it was to switch to Unicode. At least it treats integers as true integers rather than your CPU's concept of an integer.

xapata 6y ago

You get type errors if you try to combine two values with different timezones. I think of naive as a null timezone and it makes sense to me. Why is it so different?

alanfranz 6y ago
> You get type errors if you try to combine two values with different timezones. What kind of type errors? Maybe you mean naive and tzaware objects? Working on two tzaware objects with different offsets should not yield any error. Otherwise, it's worse than I thought. > null timezone What is a null timezone? Can you make an example of how it would be used in the real world? If you want something for a point in time, you need an attached offset. That's an Instant in java.time. If you need something more "human", then you get a LocalDateTime (in java.time parlance). Which is not a point in time unless you attach an offset to it, or localize it through a timezone. Some operations just don't make sense between LocalDateTime. Example: can you measure the number of hours between one localdatetime and another localdatetime (or even an instant) ? No; because you don't know either offset. Python doesn't prevent such operations; it tries to make things work in a simpler, but wrong way. Date/time handling is one of the hard things to get always right in software engineering; simplification doesn't work.
- xapata 6y ago
  > tries to make things work in a simpler, but wrong way To be fair, it is an old language. Before Python 3, it used the old assumptions about text being just 1-byte characters. We all know how much trouble it was to switch to Unicode. At least it treats integers as true integers rather than your CPU's concept of an integer.