Z + an offset parses as UTC for ZonedDateTime

[Manishearth]

1970-01-01T00:00Z[+01:00] should parse as having a UTC offset (i.e, it should parse as a ZDT with Instant = -1h), but it doesn't.

This causes the zoneddatetime-string test262 failures.

Haven't yet investigated what is going on here, but figured I would at least file an issue before logging off for the day.

[Manishearth]

temporal/src/builtins/core/zoneddatetime.rs

Lines 1294 to 1296 in 3e6c99d

	let UtcOffsetRecordOrZ::Offset(offset) = record else {
	return (None, true);
	};

forces Z to mean a zero offset

but looking at https://tc39.es/proposal-temporal/#sec-temporal-totemporalzoneddatetime and https://tc39.es/proposal-temporal/#sec-temporal-interpretisodatetimeoffset it seems like Z forces EXACT offsetBehavior which still reads offsetNanoseconds.

I'm not quite sure how this parser code maps to the spec so I don't know what I should and shouldn't change.

[Manishearth]

Oh, I think we also need to support treating timezone annotations as annotations

In addition to the above deviations, any number of conforming RFC 9557 suffixes in square brackets are allowed. However, the only recognized suffixes are time zone and BCP 47 calendar. Others are ignored, unless they are prefixed with !, in which case they are rejected. Note that the suffix keys, although they look similar, are not the same as keys in RFC 6067. In particular, keys are lowercase-only.

IXDTF itself does not parse offsets in square brackets, but RFC 9557 does.

[nekevss]

ixdtf does parse the time zone annotation. It does not resolve any conflicts between the offset and timezone. The logic is just not being resolved like it should be in ZonedDateTime::from_str_with_provider, primarily because I think this could predates ixdtf properly handling Z.

This sort of seems in scope of #379 and any follow up work to address parsing. In the short term, the logic here could be built out to be more thorough than current.

[Manishearth]

Yeah, after talking with @sffc I understand things better:

• Z means that the provided date/time is UTC ("you are setting exact time")
• [offset] means that the provided date/time is in a particular timezone. If there is no Z, it means that the provided date/time was wall time, not exact time.
• Z[offset] means the provided date/time should be interpreted as UTC and then projected into the timezone.

With this in mind, the bug appears to be that ZonedDateTime::from_str_with_provider is ignoring the tz field in the result when Z is set. Or something like that.

[Manishearth]

Lol interpret_isodatetime_offset just has a TODO: Deal with offsetBehavior == wall in it.