start_date and deadline are off by one day

To Reproduce
Create a task in Things with a start date of December 7th and a deadline of December 10th.
Find the task in things.upcoming() and compare start_date and deadline with what is shown in Things:

>>> pprint(things.upcoming()[12])
{'created': '2021-11-28 18:07:11',
 'deadline': '2021-12-09',
 'index': -1419,
 'modified': '2021-11-28 18:07:39',
 'notes': '',
 'project': '44Sevodr3k4XbXaczpdoeF',
 'project_title': 'misc. personal tasks',
 'start': 'Someday',
 'start_date': '2021-12-06',
 'status': 'incomplete',
 'stop_date': None,
 'title': 'create example for GitHub issue',
 'today_index': 8376659,
 'type': 'to-do',
 'uuid': '7E6YNbvGhuDXTbSEczebx5'}
>>>

Note that I'm in California, USA, so currently in Pacific Standard Time (UTC - 8), in case that's relevant.

Expected behavior
I expected start_date and deadline to match what is shown in Things.
Interestingly, the created and modified timestamps are correct.

Additional context
Screen shot of task in Things:

Well written bug report ;) The root cause is probably that we're using date in

things.py/things/database.py

Line 526 in 19fac2b

date(TASK.startDate, "unixepoch", "localtime") AS start_date,

and

things.py/things/database.py

Line 527 in 19fac2b

date(TASK.{DATE_DEADLINE}, "unixepoch", "localtime") AS deadline,

and datetime in

things.py/things/database.py

Line 529 in 19fac2b

datetime(TASK.{DATE_CREATED}, "unixepoch", "localtime") AS created,

and

things.py/things/database.py

Line 530 in 19fac2b

datetime(TASK.{DATE_MODIFIED}, "unixepoch", "localtime") AS modified,

However, I'll not find time working on this any time soon. @mikez maybe?

@cjchapman Thanks for the wonderful report and @AlexanderWillner for pinging me.

I submitted a fix. @AlexanderWillner Would you enjoy to write a test for the PST timezone and upload the new version to PyPI?

Technical details:

The root cause was a misunderstanding of how Things.app stores date types. It turns out, that they're for the most part stored as "00:00 UTC" datetimes. Thus, if you're in California, then that will shift the date by one day when the "localtime" modifier is applied. However, for stop_date this does not seem to apply, since there the entire datetime is captured in the database—note just the date.

Thanks again @cjchapman, I'm glad you reached out to us. If you have any feedback about the API in terms of usability, I'd love to hear. Feel free to email me.

P.S. @AlexanderWillner: If you find time, also take a look at the stop_date comment here.

@mikez Thanks for the fix. I just tried it out and I'm getting the dates I expect now. 😀

I'm currently using the API indirectly, via things-cli, but if I start using the API directly, I'll be sure to send you any feedback I may have.

Part of Release 0.0.14. Thanks!

@AlexanderWillner 👍 As stated earlier, would you enjoy to write a test for the PST timezone? To make sure this doesn't happen again.