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>
- Restores behaviour which got lost when switching to the new interval filtering in 9968b9e9
- Add test for each command
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
I left some unused varaibles in a new test functions after copy-paste.
This addresses @laufts comments on #423.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
This fixes an error where the latest interval, a non-synthetic interval,
is added to the synthetic array (and marked synthetic) if flatten() is
otherwise not able to convert it to a group of synthetic intervals.
When modify was attempting to edit this interval, it would fail since
synthetic intervals should not be written to the database unless the
database is being flattened and timewarrior believed the interval to be
modified was synthetic.
Closes#422
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
This change introduces a new command that, like lengthen, move, resize, and
shorten, is intended to move and/or resize a record, but instead of taking an
interval, will take an absolute date/time.
This command is useful because it removes the need for the user to calculate
the time intervals to shorten / lengthen a record by. For example, if the user
accidentally forgot to stop tracking an interval before starting a new one,
but new they stopped working at a specific time, it is easy to simply modify
the end time of the interval that they had forgotten to stop.
