Suggestion: Explicit tzinfo in datetimes returned by SDK

[xybu]

In the SDK, all datetimes (e.g., Item.file_system_info.last_modified_date_time) returned miss tzinfo attribute. Although UTC is assumed (strictly speaking, this isn't true because OneDrive API explicitly returns UTC timezone by Z) in OneDrive API, if the user does not pay extreme attention to timezone info and uses the value directly in some Python API where localtime is assumed when tzinfo is missing (e.g., datetime.datetime.timestamp()), some issue can happen.

If at all possible please make tzinfo explicitly UTC in the datetime objects returned. There are many fast and reliable ISO-8601 parsers out there and the slowest one is used (and in a lazy and incorrect way).

[KennethWilke]

I was noticing that my last_modified_date_times looked off, I'd see 1/24/2017 11:24 AM in the OneDrive site and Tue Jan 24 21:16:06 2017 in this SDK. Which seems pretty strange to me that the minutes are off too.

@xybu did you have a way to work around this and get the proper time?

[xybu]

@KennethWilke I believe the server manages the field Item.last_modified_date_time and it's read-only to clients (see https://dev.onedrive.com/resources/item.htm). The writable field is FileSystemInfo.last_modified_date_time which is present only for files in OneDrive Personal accounts (see https://dev.onedrive.com/facets/filesysteminfo_facet.htm).

[KennethWilke]

I understand that the server would manage that field, what's confusing me is why the time I get back doesn't match the time i see in the Web UI.

[KennethWilke]

For a more concrete example, i have a file, Document1.docx. In OneDrive's website it says Modified 1/24/2017 11:24 AM

When I grab item.last_modified_date_time i get 2017-01-24 21:16:06.260000. If I convert that to local time (GMT-6) it converts to 4 hours and 52 minutes ahead of what I'm expecting it to be

[xybu]

What's the value of item.file_system_info.last_modified_date_time? Also double check the raw string of those fields (dump item._prop_dict) because the datetime parser included in the SDK doesn't set timezone explicitly and some Python functions assume local time if timezone is absent and some assume UTC -- just be careful.

[KennethWilke]

Ah! That value does look like the proper UTC timestamp, thank you! :) Do you know what is different about the items own last_modified_date_time?

[xybu]

It seems the server updates Item.last_modified_date_time whenever its data or metadata is updated.

[baywet]

Thank you for reaching out and for your patience. This SDK is being officially deprecated. See #209 for more information