4 ms·

I've recommended people stay far away from arrow for many years now. The basic problem is on their "features" list: > [the standard library has] too many types

by boxed 6y ago

I've recommended people stay far away from arrow for many years now. The basic problem is on their "features" list: > [the standard library has] too many types No. That's just not at all true. In fact I would argue it's the opposite. You can make some very bad mistakes in python with dates because they silently coerce into each other in nonsensical ways. Arrow makes this much worse. A date is not the same as the millisecond at the start of thst date!

xapata 6y ago
Mind giving an example?
dmix 6y ago
I wonder if this is Arrow or working with datetimes in programming in general. These such as Arrow, like moment.js, are good for UIs. But if you require plenty of date manipulation then I’d keep it native as possible with plenty of tests. An example would be good as well. I think dates have been my worst experience working in programming across a multitude of languages.
symlinkk 6y ago
Just seems like the age old problem of Python not having types built in.
- dragonwriter 6y ago
  What does the absence of (static) types have anything to do with the issue here?
alanfranz 6y ago
> 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.
rswail 6y ago
A date specifying a day is a Duration. A date that is a truncated/rounded timestamp is the same as the millisecond at the start of that date. 2021-02-27T00:00:00.000Z === 2021-02-27 if truncating. But the day 2021-02-27, first of all starts and ends at different times, depending on your local timezone, but for me it's (in ISO8601 format) 2021-02-27T00:00:00.000+11/P24H. To cover the whole world, it would be 2021-02-27T00:00+12/2021-02-27T23:59:59-12 or 2021-02-26T12:00Z/2021-02-28T11:59:59Z which is 48 hour duration :)

by boxed 6y ago

xapata 6y ago

Mind giving an example?

dmix 6y ago

I wonder if this is Arrow or working with datetimes in programming in general. These such as Arrow, like moment.js, are good for UIs. But if you require plenty of date manipulation then I’d keep it native as possible with plenty of tests. An example would be good as well. I think dates have been my worst experience working in programming across a multitude of languages.

symlinkk 6y ago

Just seems like the age old problem of Python not having types built in.

dragonwriter 6y ago
What does the absence of (static) types have anything to do with the issue here?

alanfranz 6y ago

> 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.

rswail 6y ago

A date specifying a day is a Duration. A date that is a truncated/rounded timestamp is the same as the millisecond at the start of that date. 2021-02-27T00:00:00.000Z === 2021-02-27 if truncating. But the day 2021-02-27, first of all starts and ends at different times, depending on your local timezone, but for me it's (in ISO8601 format) 2021-02-27T00:00:00.000+11/P24H. To cover the whole world, it would be 2021-02-27T00:00+12/2021-02-27T23:59:59-12 or 2021-02-26T12:00Z/2021-02-28T11:59:59Z which is 48 hour duration :)