Closed majurgens closed 2 years ago
The value is just a Python datetime object, thus the default format is as described by Python, not Microsoft.
However, to support the WQL format described by Microsoft, I've added the dt_fmt(..)
for the correct output. e.g:
from aiowmi.tools import dt_fmt
# Say, for example we have a prop.value of type datetime:
print(dt_fmt(prop.value)) # Outputs the following: 2022-06-21 12:18:17+600
(see pr #13)
Thanks for the fast response.
So I think you are saying that someone calling aiowmi has to read all the values and then correct ones that are wrong? Wouldn't it make more sense for aiowmi just to send back the right format everytime so that callers just get the correct value?
Perhaps by getting aiowmi to return a python native value it makes it easier for using the returned value in python? Yeah, maybe that is why you did it like this
Also, I think your fix is missing the mmm (milliseconds) part of the date/time As per "Format valid only in WMI Query Language (WQL) queries. yyyy-mm-dd HH:MM:SS:mmm"
I added the fix for this to my existing PR https://github.com/cesbit/aiowmi/pull/11/files#diff-7a7ddf3c6f840cdf885729fd8ebaa9b0a6441a4a6574e03bf533ec6df815084d
Hopefully that is ok
This PR (https://github.com/cesbit/aiowmi/pull/8) started returning timezone data. However, it seems to return an invalid timezone format.
I believe that the timezone offset is supposed to be a 3 digit number of minutes as per UUU in https://docs.microsoft.com/en-us/windows/win32/wmisdk/cim-datetime. The code seems to return HH:MM format.
For example, running a query like:
SELECT Name,LastModified WHERE Name="c:\\pagefile.sys"
returns a date like 2022-06-21T12:18:17.537989+10:00 where the timezone is +10 hours
Native Windows clients return a date like 2022-06-21T12:18:17.537989+600 where the timezone is +600 minutes (correct as per documentation)