Offsets from UTC are defined in whole hours and minutes, never with seconds.
FixedOffset stores the offset from UTC in seconds, which makes sense because it allows for fast calculations.

I propose to enforce the value of FixedOffset is always a multiple of 60.
This prevents a number of existing or potential problems:

• RFC 2822 and RFC 3339 don't allow seconds. Chrono currently can create invalid strings with offset formatted as hh::mm::ss.
• The resulting string can not be parsed by chrono.
• This also effects serialization with serde.
• Leap seconds should always occur after the 59th second. Having an offset with seconds can place it after any other second, making a mess.

I mainly want to make this change because it prevents those problems.
Enforcing FixedOffset is always a multiple of 60 enables a nice possibility: it can fit inside an i16 if we shift the value 2 bits (which we can, 60 is divisable by 4). This creates room for niche optimization: <Option<DateTime<FixedOffset>>> now only requires 16 bytes instead of 20.

Could this effect users of chrono?
It is pretty much a rule that whenever you start checking something you didn't before, it catches some problems. Because Unix, Windows and the IANA timezone database don't allow seconds to define offsets, and because chrono can barely parse them (only with the %::z specifier), I don't expect any issues in real-world uses. But it may trip up some artificial test.