-
Notifications
You must be signed in to change notification settings - Fork 53
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
Use DateTimeOffset Instead of Int64/long for Dates #119
base: master
Are you sure you want to change the base?
Use DateTimeOffset Instead of Int64/long for Dates #119
Conversation
Using DateTimeOffset instead of DateTime will allow us to force use of UTC with the API even if the consumer wants to use local timezones.
I’ve had to do the same thing all the time. This is a great update to take. |
Just as an FYI, I've run into a couple of bugs with these changes that I'm working through now. I'll push any changes here and advise when everything is working properly. |
No need to forward to the next token. We can just get the value of the current property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @DotJoshJohnson! So sorry for the delay in getting back to you here. Can you please add also how this changes the instructions we have in the readme? And can you squash the commits into just one? Thank you in advance! 🤜 🤛
No worries! I've actually gotten sidetracked with other priorities myself. I'll jump back in here as soon as I can to get these changes in place. Thanks for the consideration! |
@DotJoshJohnson no rush at all. Thank you once again. 🙇 |
I've found myself adding helper classes to convert the UNIX timestamps in the Intercom models to
DateTime
objects for use with our business logic. This PR changes allInt64
/long
implementations in the models toDateTimeOffset
(orDateTimeOffset?
where applicable) and implements a JsonConverter to ensure dates are always represented as UNIX timestamps in UTC when serialized to JSON for the API.If this PR doesn't align with the direction of the project, feel free to simply close it. I just wanted to share in case anyone found it useful. Thanks!