Add easy initialization macros

[pitdicker]

trafficstars

I am very happy to have something like this!

// NaiveDate
date!(2023-09-08); // calendar date
date!(2023-251); // ordinal date

// NaiveTime
time!(7:03); // seconds are optional
time!(7:03:00);
time!(23:59:60); // leap second

// NaiveDateTime
datetime!(2023-09-08 7:03);
datetime!(2023-09-08 7:03:25);

// DateTime<FixedOffset>
datetime!(2023-09-08 7:03:25+02:00);
datetime!(2023-09-08 7:03:25-02:00);

My macro skills are not great though. I do not know how to avoid the code duplication. And I can't make the time! macro support fractional seconds yet. Something TT muncher something.

~Depends on https://github.com/chronotope/chrono/pull/1069 for creating a const DateTime<FixedOffset>.~

Fixes https://github.com/chronotope/chrono/issues/13.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 71.92982% with 32 lines in your changes are missing coverage. Please review.

Project coverage is 91.67%. Comparing base (6c4e735) to head (2d52c4b).

Files	Patch %	Lines
src/macros.rs	71.92%	32 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1270      +/-   ##
==========================================
- Coverage   91.79%   91.67%   -0.13%     
==========================================
  Files          37       38       +1     
  Lines       18185    18299     +114     
==========================================
+ Hits        16693    16775      +82     
- Misses       1492     1524      +32     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[pitdicker]

Another open problem: clippy warns about integers starting with 0, which is common in date and time values.

[djc]

Another open problem: clippy warns about integers starting with 0, which is common in date and time values.

Can probably add clippy #[allow()] attributes in the macro output?

[pitdicker]

Fixed the clippy warning with help from @Alexendoo in https://github.com/rust-lang/rust-clippy/issues/11472.

[pitdicker]

• The macro to create a DateTime<FixedOffset> hits the same problem as in https://github.com/chronotope/chrono/pull/1286#issuecomment-1716972437: Rust 1.57 doesn't support making DateTime<Tz>::from_naive_utc_and_offset const. Added a workaround.
• We can't easily see whether a macro is const, so I added a test for it.
• Added an offset! macro. offset!(+05:43) is a lot easier to read then FixedOffset::east_opt(20_580).unwrap().

[pitdicker]

I have separated this into smaller commits.

And by creating a temporary const inside the macros we can guarantee the values are always checked at compile time.

[pitdicker]

Updated to remove the rust 1.57 workaround.

These macro's can make tests nicer to read. Example commit: https://github.com/chronotope/chrono/commit/8e4092f97acdbced0bd57b16d15e368331ef5af4. They give us parity with one of the selling points of the time crate.

[sorairolake]

I think it would be useful to have an initialization macro for DateTime<Utc>.

// DateTime<Utc>
datetime!(2023-09-08 7:03:25Z);

// DateTime<FixedOffset>
datetime!(2023-09-08 7:03:25+00:00);

[pitdicker]

I think it would be useful to have an initialization macro for DateTime<Utc>.

Agreed. But as I understand such a syntax, using a letter after a number, is not supported by simple macro's. And my goal was to keep it simple, without resorting to proc macro's.

Note that you can do

// DateTime<Utc>
datetime!(2023-09-08 7:03:25).and_utc();

[pitdicker]

Found a way to accept a time with fractions of a second using the stringify macro!

So we can now also do time!(7:03:15.01), and the same for datetime!().

@djc What would be needed to push this PR forwards? I think it will be a really good addition to improve the ergonomics of chrono.

b.t.w. I opened https://github.com/rust-lang/rust/issues/123156 for the CI errors.