Remove partial support for handling -0000 offset

[pitdicker]

RFC 2822 and others have a special encoding to indicate the offset of a datetime is unknown: -00:00.

We currently have code in format::parse that ensures we do not provide an offset to the Parsed struct if the offset is -0000.
timezone_offset_2822 returns an Option<i32> that should be None to differentiate this case from +0000.

But then timezone_offset_2822 does return Some(0) on the -0000 input. That makes the Option and the code to handle it useless.

I would like to see proper support for encoding this value in a FixedOffset, as in #1042.

But for now the inconsistency just messes up the error variants we return.
Because I am currently working on converting the parsing code from ParsedError to a new Error type for 0.5, I just need something consistent to work on.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (b92b736) 91.84% compared to head (1d1b336) 91.84%.
Report is 19 commits behind head on main.

❗ Current head 1d1b336 differs from pull request most recent head 18d8459. Consider uploading reports for the commit 18d8459 to get more accurate results

Files	Patch %	Lines
src/format/parse.rs	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1411      +/-   ##
==========================================
- Coverage   91.84%   91.84%   -0.01%     
==========================================
  Files          38       38              
  Lines       17518    17517       -1     
==========================================
- Hits        16090    16089       -1     
  Misses       1428     1428              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djc]

I'd like for this to be two commits:

• One for using a constant and the reformulated Range::contains()
• One for changing the value from 86400 to 863400

I also think 23 * 3600 + 59 * 60 is a surprising way to express this? I think (24 * 60 - 1) * 60 might be clearer.

[pitdicker]

I also think 23 * 3600 + 59 * 60 is a surprising way to express this? I think (24 * 60 - 1) * 60 might be clearer.

It comes from the definition in RFC 3339 as copied in comment of this function:

// time-hour = 2DIGIT ; 00-23
// time-numoffset = ("+" / "-") time-hour ":" time-minute
// time-minute = 2DIGIT ; 00-59
// time-offset = "Z" / time-numoffset

[djc]

Right. (23 * 60 + 59) * 60 could also work, I guess, but I find the previous suggestion more intuitive. I'll leave it up to you.

[pitdicker]

Done. Added 'Max for the hours field is 23, and for the minutes field 59.' as a comment.