Matthew Schinckel

Is there something we can do in PyXero to make this "handled" better? (Or is this resolved and I can close it?)

Can you supply a link for the documentation? The HTTP specification asserts that this header should not be an ISO8601 timestamp. (I'll take it up with Xero developer relations if...

This is similar in behaviour to things like updated timestamp.

Xero date formatting is crappy. Especially in that case, where the field name contains UTC, but the value clearly isn't!

In that particular case, you won't want to be sending back that field, because it will prevent saving: the value will be updated by Xero when you make changes.

I do have some code that (I believe correctly) interprets these values, but it's not pretty.

I believe it's potentially related to `isort` determining imports are `THIRDPARTY`, but `flake8-isort` not being able to. In my case, I have a `flake8` command that runs on saving a...

Ah, so the documentation is auto-generated.

Okay, so it seems like `fetch_access_token` would use the `realm` that is supplied as a kwarg, but other requests do not?

Can you paste a traceback? I don't use Pycharm, so I'm not sure what it's looking for.