Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency with numeric strings being converted to Datetime objects #1026

Open
christianmartinroffey opened this issue Dec 11, 2024 · 4 comments
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience

Comments

@christianmartinroffey
Copy link

christianmartinroffey commented Dec 11, 2024

Describe the bug

Hi, I'm aware that there has been a previously reported issue with numeric strings being converted to datetimes, but the issue seems to still be appearing sporadically. For example, the following two values are being passed as datetimes

6261201 > DateTime(6261, 7, 20, 0, 0, 0, tzinfo=Timezone('UTC'))

3876001 > DateTime(3876, 1, 1, 0, 0, 0, tzinfo=Timezone('UTC'))

31160705 > DateTime(3116, 7, 5, 0, 0, 0, tzinfo=Timezone('UTC'))

There are other 7 and 8 digit values that this isn't happening for making it tricky for me to pin point commonalities and narrow down the issue.

Expected behavior

For the values to be saved as non-datetime objects

How to reproduce

this is the query

members = await self.client.groups.by_group_id(group_id).members.get()

email_dict = {
member.mail: member.additional_data.get(self.supplier_param)
for member in members.value
}

Note: there are other 7 digit numerical values that are being casted correctly, and I haven't been able to reproduce with any other length.

SDK Version

1.14.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output

Click to expand log ```
</details>


### Configuration

_No response_

### Other information

_No response_
@christianmartinroffey christianmartinroffey added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience labels Dec 11, 2024
@chandra447
Copy link

chandra447 commented Dec 17, 2024

hi @christianmartinroffey i have a similar issue, for some reason i dont understand what they have done with packaging all the kiota-serializations as a single package i mean for all the languages,
but this PR fixed the issue. i manually updated the json_parse_node.py in my .venv to check if that resolves the issue.

Based on my findings i feel like msgraph-sdk now uses kiota-python instead of using the old repo.
this method needs to be fixed to reflect the PR above
https://github.com/microsoft/kiota-python/blob/43b19276dfdf424708036361322c1cabda240167/packages/serialization/json/kiota_serialization_json/json_parse_node.py#L304C5-L327C100

@Kobusvdwalt
Copy link

If I understood everything correctly this would fix it.
microsoft/kiota-python#427

@christianmartinroffey
Copy link
Author

Thanks @chandra447 and @Kobusvdwalt for the help, looks like the fix has been merged so one step closer to getting it resolved

@Kobusvdwalt
Copy link

Fixed in #1038

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience
Projects
None yet
Development

No branches or pull requests

3 participants