[BUG] sqlite3 returner logs using local timezone

[nathansgreen]

Description
The sqlite3 returner logs in the local time zone. This means that a daylight saving change will cause results to appear out of order.

Setup
No special setup is needed.

Steps to Reproduce the behavior
Use the sqlite3 returner on any machine configured with a time zone.

Expected behavior
The logged return date should always go forward in time for a given minion.

Screenshots
n/a

Versions Report

Salt Version: Salt: 3001

Dependency Versions:
cffi: 1.12.2
cherrypy: unknown
dateutil: 2.8.0
docker-py: Not Installed
gitdb: 2.0.6
gitpython: 2.1.15
Jinja2: 2.10.1
libgit2: 1.0.1
M2Crypto: 0.35.2
Mako: 1.0.7
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.19
pycrypto: Not Installed
pycryptodome: 3.9.7
pygit2: 1.2.1
Python: 3.8.3 (default, Jul 8 2020, 14:27:55)
python-gnupg: 0.4.4
PyYAML: 5.1.2
PyZMQ: 19.0.0
smmap: 3.0.4
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.2

System Versions:
dist: darwin 19.5.0
locale: utf-8
machine: x86_64
release: 19.5.0
system: Darwin
version: 10.15.5 x86_64

PASTE HERE

Additional context
Add any other context about the problem here.

[krionbsd]

@nathansgreen could you please provide the salt run with end result to give us the overview what's going on

[nathansgreen]

The short answer is that datetime.datetime.now() is being used, and instead utcnow() should be used.

[cmcmarrow]

#58003

[cmcmarrow]

@nathansgreen I see lint and pr-commit is failing. You can fix this by running pre-commit

pip3 install pre-commit
pre-commit install in the root of the salt git repo

Its okay to mock all the sql calls for your test.

[sagetherage]

the Core team will not be able to get to this in Aluminium but we will review a PR if anyone in the community wants to submit one, moving to Approved until a test case can be written on the PR