It’s AI, so not surprising

And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.

You should look at it, they say the implement RFC 9556 timestamps, which include tz info. In my experience it IS useful in real use, because a fixed offset timestamp can lose a bit of information.

For example, if you have a timestamp and want to add a few months to it, for example for a reminder, you will get a timestamp at the same time in the same offset. In many cases that will be wrong, because of things like daylight savings time, which change the offset of the timezone. You will get a timestamp an hour before or after the moment you intended, and it will be in the “wrong” offset in that timezone in that time of year. With timezone aware timestamps, they are aware that the offset will change, and will be able to give a timestamp in the future at the correct time and offset.

In this section, wouldn’t be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

They do say that the difference is that chrono users would need to keep out-of-band timezone information in addition to the datetime, whereas Jiff does it in-band.

Yep, four of them, hence the “Q”.

LLDB?