Replies: 2 comments 2 replies
-
|
There may be a solution with a custom |
Beta Was this translation helpful? Give feedback.
-
|
Found some more discrepancies, the most glaring of which is timestamp is a property on this leads to some fun issues with |
Beta Was this translation helpful? Give feedback.
-
|
Hey @onerandomusername, in Arrow 1.0+ time stamp is now a function to align with the datetime API. We still support time stamps as properties through |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I was using a very old version to check on, sorry for the confusion here! 🙃 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Can #133 be reconsidered?
There are two ways in which implementing the interface without subclassing is causing problems:
arrow.Arrowis used wheredatetime.datetimeordatetime.dateis expected.arrow.Arrowdoes not pass anisinstance(datetime.datetime)check. Arguably such check shouldn't be done, but if I am using a library that does this, then there's nothing I can do but usearrow.Arrow.datetime.Using
arrow.Arrow.datetimeis a solution, but it's not as elegant as being able to passarrow.Arrowdirectly.The downside might be that despite implementing the same interface, some functions may have different semantics than
datetime.datetime. This could lead to unexpected results when expecting adatetime.datetime. I haven't analysed it thoroughly, but it seems that most of the differences would be with classmethods rather than instance methods; it's rare to pass the type around rather than an instance, or to use classmethods on an instance.Is the stance still the same as it was 7 years ago? What are everyone's thoughts now?
Beta Was this translation helpful? Give feedback.
All reactions