In the upcoming version 0.15.0 of arrow, we will be making a lot of changes to the behavior of arrow.get() to address a number of reported parsing bugs. We have outlined the changes below:

Fixes

• Most instances of arrow.get() returning an incorrect arrow object from a partial parsing match have been eliminated.

For example,

>>> arrow.get("garbage2017everywhere")
<Arrow [2017-01-01T00:00:00+00:00]>

>>> arrow.get('Jun-2019', ['MMM-YY', 'MMM-YYYY'])
<Arrow [2020-06-01T00:00:00+00:00]>

These will raise a ParserError in 0.15.0.

• When a meridian token (a|A) is passed and no meridians are available for the specified locale (e.g. unsupported or untranslated), a ParserError is raised.
• Timestamp strings are no longer supported in the arrow.get() method without a format string: arrow.get("1565358758"). This change was made to support the ISO 8601 basic format and to address bugs such as https://github.com/crsmithdev/arrow/issues/447.

The following will still work as expected:

arrow.get("1565358758", "X")
arrow.get("1565358758.123413", "X")
arrow.get(1565358758)
arrow.get(1565358758.123413)

• The timestamp token (X) will now matches float timestamps: arrow.get("1565358758.123415", "X").
• The timestamp token (X) will now only match on strings that strictly contain integers and floats, preventing incorrect matches.

New Features

• ISO-8601 basic format style is now supported (e.g. YYYYMMDDThhmmssZ)
• Added support for DDD and DDDD ordinal date tokens (e.g. "1998-045")

Issues addressed

• https://github.com/crsmithdev/arrow/issues/560
• https://github.com/crsmithdev/arrow/issues/538
• https://github.com/crsmithdev/arrow/issues/434
• https://github.com/crsmithdev/arrow/issues/519
• https://github.com/crsmithdev/arrow/issues/91
• https://github.com/crsmithdev/arrow/issues/447
• https://github.com/crsmithdev/arrow/issues/196
• https://github.com/crsmithdev/arrow/issues/456
• https://github.com/crsmithdev/arrow/issues/396

Development progress

You can view the progress of these changes here: https://github.com/crsmithdev/arrow/tree/Version-0.15.0.

Disable Warnings

To get rid of the ArrowParseWarning messages in 0.14.3 onwards, do the following:

import warnings
from arrow.factory import ArrowParseWarning

warnings.simplefilter("ignore", ArrowParseWarning)

Hello,

New release (0.11.0) is broken for Python 2.x users, below you can find steps to reproduce:

~/.virtualenvs/tmp-455f8c1518baad7 via tmp-455f8c1518baad7
➔ python --version
Python 2.7.14

~/.virtualenvs/tmp-455f8c1518baad7 via tmp-455f8c1518baad7
➔ pip install arrow
Collecting arrow
Collecting python-dateutil (from arrow)
  Using cached python_dateutil-2.6.1-py2.py3-none-any.whl
Collecting six>=1.5 (from python-dateutil->arrow)
  Using cached six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, python-dateutil, arrow
Successfully installed arrow-0.11.0 python-dateutil-2.6.1 six-1.11.0

~/.virtualenvs/tmp-455f8c1518baad7 via tmp-455f8c1518baad7
➔ python
Python 2.7.14 (default, Sep 25 2017, 09:53:22)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import arrow
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ng/.virtualenvs/tmp-455f8c1518baad7/lib/python2.7/site-packages/arrow/__init__.py", line 3, in <module>
    from .arrow import Arrow
  File "/Users/ng/.virtualenvs/tmp-455f8c1518baad7/lib/python2.7/site-packages/arrow/arrow.py", line 19, in <module>
    from arrow import util, locales, parser, formatter
  File "/Users/ng/.virtualenvs/tmp-455f8c1518baad7/lib/python2.7/site-packages/arrow/parser.py", line 12, in <module>
    from backports.functools_lru_cache import lru_cache  # pragma: no cover
ImportError: No module named backports.functools_lru_cache
>>>

Could you fix this please?

In paris in 2013, we changed to DST in 2013-03-31 (at 2 AM it was 3 AM), from UTC+1 to UTC+2 (DST)

Here's an example of the issue I have with arrow :

>>> import arrow, datetime

>>> just_before = arrow.get(datetime.datetime(2013, 03, 31, 1, 50, 45), "Europe/Paris").ceil("hour")
>>> just_before
<Arrow [2013-03-31T01:59:59.999999+01:00]>

>>> just_after = just_before.replace(microseconds=+1)
>>> just_after
<Arrow [2013-03-31T02:00:00+02:00]>
>>> # That is not right... It should be either 2 AM UTC+1 or preferably  3AM UTC +2
>>> # One could argue that depending on what you ask for, it may be the correct answer, but then the following is :

>>> (just_after - just_before).total_seconds()
1e-06
>>> # That is right but not consistent with the dates

>>> (just_after.to("utc") - just_before.to("utc").total_seconds()
-3599.999999
# That should be the same value as the previous computation. Plus, the value is negative because :

>>> just_before.to('utc'), just_after.to('utc')
(<Arrow [2013-03-31T00:59:59.999999+00:00]>,
 <Arrow [2013-03-31T00:00:00+00:00]>)

I think the problem is pretty clear...

This thread was originally opened to request GitHub release and changelogs. That has been done, and the thread is now used as roadmap and ideas. Scroll to the bottom to see them. Thanks @crsmithdev and maintainers!

Hi! First of all, I would like to say that arrow is very well done and suits very well for almost everything a programmer wants. The only step back in arrow, IMHO (or to my necessity), is the "factory" design for getting an instance of the Arrow class. Why? I just want to extend Arrow's class to add some of methods I often use in datetime conversions / comparison :) If I choose to inherit Arrow, I would have to duplicate everything from "api" OR monkey patch it - which I don't like at all. Any ideas on how to circumvent this? Maybe a register method in the "api" for Arrow' subclasses? I can help with that, if possible :)

Best regards, Richard.

…ng span in combination with frame == "week"

Pull Request Checklist

Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

• [x] 🧪 Added tests for changed code.
• [ ] 🛠️ All tests pass when run locally (run tox or make test to find out!). --> see comments below
• [ ] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!). --> see comment below
• [x] 📚 Updated documentation for changed code.
• [x] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!

Description of Changes

Closes: #355 This is my first PR and I choose this issue because it was labeled as 'good first issue'. I added a new parameter weekday that can be used in combination with frame == "week" to choose a start day for arrow.span().

My tests weren't successful. There was an issue with Python3.6 and an error. I ran the tests again against the master code and encountered the same error, see screenshots:

Master Error: Master Summary:

These where the only problems I encountered after implementing my changes.

Furthermore I had problems running the linting, I got the following message:

I hope we can resolve these issues. Thank you and kind regards.

Issue Description

This is a bit specific, but I'm grasping for straws at this point. So I'm using arrow via a kodi script. And it works without problems on linux. A team member tried using my script on windows 10, he get's this stack trace.

2019-12-14 10:29:01.961 T:1472   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <class 'AttributeError'>
                                            Error Contents: 'datetime.timedelta' object has no attribute 'tzinfo'
                                            Traceback (most recent call last):
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\metadata.tvdb.com.python\scraper.py", line 3, in <module>
                                                from resources.lib import actions
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\metadata.tvdb.com.python\resources\lib\actions.py", line 10, in <module>
                                                from . import series
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\metadata.tvdb.com.python\resources\lib\series.py", line 11, in <module>
                                                from .ratings import ratings
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\metadata.tvdb.com.python\resources\lib\ratings.py", line 6, in <module>
                                                from .trakt_rating import get_trakt_rating_and_votes
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\metadata.tvdb.com.python\resources\lib\trakt_rating.py", line 1, in <module>
                                                from trakt import Trakt
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.trakt\lib\trakt\__init__.py", line 3, in <module>
                                                from trakt.client import TraktClient
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.trakt\lib\trakt\client.py", line 3, in <module>
                                                from trakt.core.configuration import ConfigurationManager
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.trakt\lib\trakt\core\configuration.py", line 3, in <module>
                                                from trakt.core.context_collection import ContextCollection
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.trakt\lib\trakt\core\context_collection.py", line 3, in <module>
                                                from trakt.core.helpers import synchronized
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.trakt\lib\trakt\core\helpers.py", line 9, in <module>
                                                import arrow
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.arrow\lib\arrow\__init__.py", line 3, in <module>
                                                from .api import get, now, utcnow
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.arrow\lib\arrow\api.py", line 10, in <module>
                                                from arrow.factory import ArrowFactory
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.arrow\lib\arrow\factory.py", line 19, in <module>
                                                from arrow.arrow import Arrow
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.arrow\lib\arrow\arrow.py", line 1396, in <module>
                                                Arrow.max = Arrow.fromdatetime(datetime.max)
                                              File "C:\KODI\KODI- v19 nightlies\portable_data\addons\script.module.arrow\lib\arrow\arrow.py", line 217, in fromdatetime
                                                if dt.tzinfo is None:
                                            AttributeError: 'datetime.timedelta' object has no attribute 'tzinfo'
                                            -->End of Python script error report<--

System Info

• 🖥 OS name and version: Running on Windows 10, kernel: Windows NT x86 64-bit version 10.0.18362
• 🐍 Python version: 3.7 (this might be connected as my linux system is already running 3.8)
• 🏹 Arrow version: 0.15.4

In French, hours are formatted as "8 h 40" and not as "8:40". But in an arrow's format string, h displays directly the hours. Would it be possible to add a key (such as !) to force h to be displayed normally ("hh !h mm")?

Issue Description

Arrow does not seem to perform validation on timestamps for unusual formats where the information conflicts.

The following code snippet runs just fine:

>>> arrow.get("2021-01-30 14:00:00 AM", "YYYY-MM-DD hh:mm:ss A")
<Arrow [2021-01-30T14:00:00+00:00]>

First of all, since hh is documented to go to a maximum value of 12, I expect arrow to raise an error because the value is 14. Secondly, I expect arrow to notice that 14:00:00 (2 PM) conflicts with the string "AM".

Is this behaviour intentional? Or is it a bug?

System Info

• 🖥 OS name and version: macOS 11.2.3
• 🐍 Python version: Python 3.7.8
• 🏹 Arrow version: 1.0.3

Python 2 is reaching EOL in 2020 (https://pythonclock.org/).

Me and @jadchaar have chatted about this before but haven't come to a decision yet. We'd hoped that the DST upgrades would be done before the EOL so Python 2.7 users would at least have access to those improvements. However due to being busy we've not had time to work on that.

An important factor in this decision will be how long travis-ci supports 2.7.

dateutil discussion - https://github.com/dateutil/dateutil/issues/653

@hugovk do you have any thoughts or stats on Python 2.7 usage?

I’ve been perusing the docs for 10 minutes now trying to figure this out. I’d think it’s a common-enough use case that it should have an example in the docs.

It seems I should use arrow.get(datetime_string, pattern_string) but I don’t know what syntax to use for the pattern, and the docs don’t say what syntax is used so I can’t look it up.

So, some suggestions:

1. add an example of parsing an ISO-8601 datetime string (with an offset)
2. add a link to the docs for the pattern syntax
3. add a module containing some “constants” with common datetime pattern strings

Pull Request Checklist

Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

• [ ] 🧪 Added tests for changed code.
• [ ] 🛠️ All tests pass when run locally (run tox or make test to find out!).
• [ ] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
• [ ] 📚 Updated documentation for changed code.
• [ ] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!

Description of Changes

Hi, I am a new contributor here. I added on function called time_diff() on the arrow.py file to count the time difference in different time zone. I passed all of the test on local.

The shift function takes some time than absolute adding of relativedelta to datetime. If I am operating on a range where I know there is no dst change I should be able to bypass this check.

Issue Description

I read #755 and thought that Arrow objects supposed to work with pandas TimeStamp object. However, I couldn't get them to work together without accessing the property "naive".

The Arrow objects couldn't be parsed using pd.to_datetime I couldn't sliced pandas Timestamp using Arrow objects as well. Is this how it's supposed to be?

I really like arrow that I can get the floor and ceiling of a frame so fast, however, it's kind of quirky to have to access .naive everytime I interact with pandas

System Info

• 🖥 OS name and version: Debian Linux 11.5
• 🐍 Python version: 3.10.6
• 🏹 Arrow version: 1.2.3

Pull Request Checklist

Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

• [ ] 🧪 Added tests for changed code.
• [x] 🛠️ All tests pass when run locally (run tox or make test to find out!).
• [x] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
• [ ] 📚 Updated documentation for changed code.
• [x] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!

Description of Changes

These changes were made in collaboration with @khanm3

• Modified the setup file so that the entire Arrow library is compiled using Cython
• Modified the tox.ini file to support code coverage with Cython
• Added Cython 3.0.0a11 to the requirements.txt
• Modified arrow.py to compile with Cython and pass the test suite
• Modified an existing test case to work with Cython since the mocking was broken from Cython caching builtins
• Added a Makefile target to compile with Cython

This pull request adds Cython support to Arrow as requested by #617.

Further Explanation

In arrow/arrow.py, we had to change the variable "locale" to "locale_cls" because the variable was being reused for 2 different types and this functionality was incompatible with Cython. Cython also had difficulties recognizing the type of _datetime.isoclanedar, so we had to specifically cast it to a tuple. Without this, it would not compile.

Even with the issues mentioned above, we chose to use Cython 3.0.0a11 (which is a pre-release version) instead of Cython 0.29.32 (the most recent stable version), since from our testing, Cython 3 is better at parsing modern Python features. In general, Cython tries to subsume the functionality of python, but as you can see there are still many quirks.

We were able to allow Cython to use the existing method of calculating code coverage by adding linetracing as a compiler directive. However, due to the quirks of Cython, the resulting line coverage results are slightly lower than 100%. We found that the lines that were no longer being covered were one of 2 cases:

1. Inside an if statement that had 'pragma no cover' (so those also shouldn't count towards coverage)
2. Parameters to functions that had a default value (which also shouldn't count towards coverage, but for some reason Cython thinks it should)

This could be ignored by adding more 'pragma no cover', but we're not sure if there is a better way.

Performance Analysis

To compare performance of Arrow with and without Cython, we ran just the Arrow part of this benchmark. This benchmark runs 1 million executions per benchmark and picked the min of 5 repeats. This was run in Python 3.8.10.

From these results, you can see that compiling Arrow with Cython does cause a measureable improvement to performance, especially with parsing. Additionally, compiling Cython without linetracing is even more performant, but we currently compile with it so that code coverage can be calculated.

Future Work

Adding static typing (and necessarily converting those files to .pyx files) would bring an even bigger boost to performance. Parser.py should receive special attention, as this is where the largest amount of time is being spent. This is where adding Cython to Arrow could prove to be especially valuable, since the speed increase with static typing should be much more than that gained by simply compiling with Cython. Looking into different ways of calculating code coverage so linetracing is no longer needed, or providing an option to switch the compiler directive would also be a good way to improve performance in the future.

Pull Request Checklist

Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

• [x] 🧪 Added tests for changed code.
• [x] 🛠️ All tests pass when run locally (run tox or make test to find out!).
• [x] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
• [ ] 📚 Updated documentation for changed code.
• [x] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!

Description of Changes

These changes were made in collaboration with @khanm3

• Modified the _ONE_OR_TWO_DIGIT_RE regex to not accept numbers with leading zeros. This is done in order to conform to the expected behavior and throw an error when, for example, you try to match '01' with 'M'. The issue #1084 only mentions the 'M' token, but realized that the 'D', 'H', 'm', 'h', and 's' have similar behavior which we have also corrected.
• Modified an existing test case since this test was using the undesired behavior which this pull request is intended to fix
• Added a test case which checks the expected behavior for all 6 tokens.

Closes: #1084

Questions:

• We also noticed that the 'DDD' token seems to have similar behavior as well. If you try to match '001' to 'DDD', should that also be expected to fail? We left that one untouched since it uses a different regex and we weren't positive.
• Unrelated to this pull request, but we noticed that tests/test_arrow.py::TestArrowHumanize::test_months is marked as expected to fail, but before we made any changes, it was already passing. Maybe this should be updated?

some tidyups for pylint

Pull Request Checklist

Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

• [N/A ] 🧪 Added tests for changed code.
• [cannot get them to run in win ] 🛠️ All tests pass when run locally (run tox or make test to find out!).
• [X ] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
• [X ] 📚 Updated documentation for changed code.
• [X ] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!

Description of Changes

Some tidyups with pylint, and black also fixed some stuff on pre-commits.