[ariebovenberg]

Author here. "Offset" is indeed relative to UTC. The problem with allowing adding timedeltas is that you give users the impression they are doing valid arithmetic, while they may not be.

Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition, you'd actually want to have 05:00:00+02:00

In the end, the choice is between "users know what they're doing, just let them" and "users need to be prevented from making common mistakes". I choose the latter.

Note that also NodaTime doesn't support arithmetic on their OffsetDateTime, for the same reason.

[magicalhippo]

> If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition, you'd actually want to have 05:00:00+02:00

Since you know the offset then adding three hours should be unambiguous no? Convert to UTC, add three hours, convert back to target timezone, which would net you the correct 05:00:00+02:00.

[Hackbraten]

> Convert to UTC, add three hours, convert back to target timezone

What if you don't even know the target offset?

You may happen to know it for an event three hours in the future, but what if you're adding three months? With that time frame, the relevant laws even may not have been passed yet.

[aimor]

Thank you for answering, I understand the dilemma now and why you chose to force users to explicitly convert to UTC.

When I see the example my thinking is: Well, if you want a time offset relative to Europe/Paris then define your time zone that way instead. Of course I haven't seen other libraries give that option and maybe for good reasons.

[ariebovenberg]

Yeah—the perfect solution doesn't exist. The problem is that fixed-offset datetimes are very common since RFC3339 and ISO8061 don't support timezone names. The result is that you often end up with fixed-offset datetimes that should instead be linked to a IANA tz ID.