Python upstream is trying to eliminate tz-naive date functions that
imply anything to do with a timezone, even UTC. They have deprecated
datetime.datetime.utcnow() in Python 3.12 and thus running tests emits
many warnings for us.
We switch to instantiate datetime objects taht are intended to reflect
UTC to have a timezone, or if we instantiate naive ones and then later
convert, we do the full conversion.
After the changes, the tests still work on Python 3.9, but now also on
Python 3.12 without warnings.
See PR description for #632 for more details.
Signed-off-by: Scott Mcdermott <scott@smemsh.net>
Move the adjustment of a new open interval that is enclosed by the
current open interval into the validation processing, where the other
overlap resolution takes place.
This will allow the start command to honor the :adjust flag when
starting a new interval that predates the current open interval.
Closes#326
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
It was possible previously to start an interval with a filter earlier
than the current filter, and if the tags matched, the command would
report success without actually moving the start time.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Since the recent switch to python3, I've been noticing that some of the tests
have been aborting with the following error when I use LANG=en_US instead of
LANG=en_US.UTF-8:
UnicodeEncodeError: 'latin-1' codec can't encode character '\u0455' in position 57: ordinal not in range(256)
Arguably, I should run with a unicode locale while running the test, but it
*looks* to me like the original ѕ was not intended.
- 'start' with more tags than current tracking should start new tracking
- 'start' with less tags than current tracking should start new tracking
- 'start' with same tags as current tracking should not start new tracking
