Renderers time conversion fixes

[gcmoreira]

In the context of volatilityfoundation/volatility3!1213 a few issues with time conversion in the framework were identified.

Aware datetimes

See warning note on https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp:

Because naive datetime objects are treated by many datetime methods as local times, it is preferred to use aware datetimes to represent times in UTC. As such, the recommended way to create an object representing a specific timestamp in UTC is by calling datetime.fromtimestamp(timestamp, tz=timezone.utc).

Additionaly, datetime.utcfromtimestamp() is deprecated since 3.12

Wrong exceptions

Since version 3.3 utcfromtimestamp() and fromtimestamp() Python datetime module raises OverflowError instead of ValueError. As of today, Volatility3 requires Python 3.7.3 so we should only include OverflowError

[gcmoreira]

hm what?

    return datetime.datetime.fromtimestamp(unix_time, datetime.timezone.utc)
ValueError: year -28 is out of range

Weird, that is NOT what the Python 3.7 standard library documentation says. It should not raise ValueError in Python 3.7.17.

Changed in version 3.3: Raise OverflowError instead of ValueError if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions. Raise OSError instead of ValueError on localtime() or gmtime() failure.

@ikelos please note that the test cases are using Python 3.7.17, while the GitHub repository specifies Python 3.7.3 or later. Although the difference is minimal, there is a untested gap there, we should consider updating either the test cases interpreter or the repository requirements for consistency. We should also consider running the test cases with both the minimum supported and latest Python versions to detect deprecation and ensure compatibility.

[gcmoreira]

Cool, all test cases pass! I've ensured consistency in exception checking for both wintime_to_datetime and unixtime_to_datetime functions.