Feature/datetime conversions

[Oracen]

What was changed

The date parsing system in temporalio.converter:decode_search_attributes is switched from datetime.datetime.fromisoformat to dateutils.parser.isoparse. This provides support for ISO8601 compliant datetime strings with timezones attached

Why?

Python's datetime library is not timezone aware by default, with issues on StackOverflow going back as far as 2008. Prior to Python 3.11, datetime.datetime.fromisoformat was not designed to handle timezone-aware datetime strings, but rather the timezone-unaware outputs of datetime.isoformat, which was not ISO compliant! (Hardest problem in SE is naming after all.)

The new Scheduling features in Temporal handle timezone-aware schedules by default. This caused issues when communicating with the Python SDK, as it could not decode the timezone strings (typically appended with 'Z' for UTC time). dateutils.parser.isoparse is known to have some problems with greedy evaluation of date strings but this typically occurs in the presence of user input. It should not be a problem for machine-formatted strings.

While the release of 3.11 means this won't be an issue in future, much of the Python and cloud ecosystem relies on older versions of Python. This change means most current versions of Python can leverage the scheduling functionality.

Checklist

1. Closes Search attribute Datetime need to support full ISO 8601 (and maybe more) #144

2. How was this tested:

• development of replication and fix (see linked issue for replication code)
• wrote unit tests to verify old/new functionality
• run against my local development project

3. Any docs updates needed?
   No

[CLAassistant]

All committers have signed the CLA.

[cretz]

This is a new dependency just for this feature. Is there any way we can avoid it? Is there any way with the standard library to do this, and/or is the parser easy to vendor/copy into here?

(also, a new dependency would need to be added to project.toml which you can do via poetry add dateutil and then re-alphabetizing)

[cretz]

Looks like it may be unavoidable to add this dependency unfortunately. Can't easily vendor stdlib impl as it's in C (ref python/cpython#92177). But can we put a if if sys.version_info >= (3, 11): here to use the stdlib version? (also don't forget to add that dependency and to run poe format).

Also, this will need to land after (and merge main after) #172 is merged which will add Python 3.11 support.

[Oracen]

Not an issue on my side, I must have been working on a tainted env because I thought dateutil was in standard. Will rebuild and double-check.

For those wondering about why this is an issue:
https://stackoverflow.com/questions/127803/how-do-i-parse-an-iso-8601-formatted-date
https://stackoverflow.com/questions/969285/how-do-i-translate-an-iso-8601-datetime-string-into-a-python-datetime-object

On doing it within the standard library, we could hack around with the following:

# Example lookup for Z
map_datetime = {
    "Z": "+00:00"
}

# ...
# v = "2020-01-01T00:00:00Z"

if v[-1].isalpha() and len(v) == 20:
    v = v[:-1] + map_datetime[v[-1].upper()]

# Code as normal

There's a slight catch here that "J" = local time, so we'd have to decide if we treat that string as timezone unaware or pull the timezone from the local machine.

The only reason I avoided this was to rely on a battle-tested date parser that could potentially catch a wider range of formats coming in from other languages. If you're confident we'll only see letters coming in (outside of the +/- hours format) then I'm happy to switch over to an explicit remap of the last digits for the sake of avoiding the external dependency

[cretz]

I think dateutil is probably an acceptable solution since it doesn't seem to carry dependencies on its own or move much.

[Oracen]

Roger that, will add in the version check and wait for the 3.11 updates you guys have planned

[cretz]

Added a couple of suggestions and need to merge main, otherwise all good. If the poetry.lock conflict is too annoying to fix, feel free to close this PR and open a new one on a fresh branch off main. Alternatively, you can wait a bit until I get around to this issue where I'll basically just copy what you did here. Thanks!

EDIT: Now that I think about it, we can just use this dependency on < 3.11. See https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies

[cretz]

Why did so much of this file change? Not that it seems wrong, just doesn't seem like the issue to do this in.

[Oracen]

Auto-sorting...I noticed you asked to re-alphabetise, I didn't realise the autoformatter did so much! Will revert

[cretz]

Sorry, I meant just the dependency, heh

[cretz]

Is it possible to also add an integration test that sets a datetime attribute in a workflow? Or maybe alter test_workflow_search_attributes so that it will break without your fix?

[Oracen]

Leave it with me

[Oracen]

Closing PR to bypass merge conflicts, new issue on #179