Rename TimeZone::timestamp* to TimeZone::and_timestamp*

[pitdicker]

We have the pattern to use the name and_ for methods that add information to convert to a more complete type.
NaiveDate had and_time and and_hms*, NaiveDateTime has and_local_timezone.

This makes the methods on TimeZone consistent. TimeZone::timestamp* is renamed to TimeZone::and_timestamp* and TimeZone::with_ymd_and_hms to TimeZone::and_ymd_and_hms*.

[codecov]

Codecov Report

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

Project coverage is 93.95%. Comparing base (3317fd1) to head (fa27e5c).

❗ Current head fa27e5c differs from pull request most recent head f80253c. Consider uploading reports for the commit f80253c to get more accurate results

Files	Patch %	Lines
src/datetime/tests.rs	98.34%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            0.5.x    #1523      +/-   ##
==========================================
- Coverage   93.97%   93.95%   -0.02%     
==========================================
  Files          37       37              
  Lines       16686    16672      -14     
==========================================
- Hits        15680    15665      -15     
- Misses       1006     1007       +1     

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

[djc]

So we may have this and_() pattern but I feel like with_() is much more common in the Rust ecosystem. Maybe we should be moving in the other direction instead? (I think that was the idea behind with_ymd_and_hms(), at least.)

Can we do some part of this on main?

[pitdicker]

Fine by me. Then we should probably rename the current with_ methods such as with_year to something like replace_year? That matches time-rs.

[djc]

How are the semantics for current with_() methods different from those for current and_() methods, in your opinion?

[pitdicker]

Currently the with_() methods return the same type and replace some part of the date, time or offset.
The and_() methods add more information to turn it into another type.

[pitdicker]

Other methods that start with and are NaiveDate::{and_time, and_hms*}, NaiveDateTime::{and_local_timezone, and_utc}.

And one more that starts with with is DateTime::with_timezone.

[pitdicker]

I'll collect some info in an issue.

[pitdicker]

Added commits to rename all methods from #1527 except TimeZone::{from_local_datetime, from_utc_datetime}.

I am not 100% conviced with the new names for NaiveDateTime::{and_local_timezone, and_utc}. Naming them in_ does match natural language. And assume_ seems like saying the user may not be sure for some reason.

Example code:

let pst = FixedOffset::east(8 * 60 * 60)?;
// in_timezone
let dt = NaiveDate::from_ymd(2018, 1, 11)?.at_hms(10, 5, 13)?.in_timezone(pst);
// assume_timezone
let dt = NaiveDate::from_ymd(2018, 1, 11)?.at_hms(10, 5, 13)?.assume_timezone(pst);

// in_utc
let timestamp = NaiveDate::from_ymd(1970, 1, 1)?.at_hms(0, 0, 0).in_utc().timestamp();
// assume_utc
let timestamp = NaiveDate::from_ymd(1970, 1, 1)?.at_hms(0, 0, 0).assume_utc().timestamp();

[djc]

This seems weird if a later commit is just going to change it again to in_utc().

[pitdicker]

I agree. This commit is merged on the main branch in #1530. I'll wait until main is merged into the 0.5.x branch again and then rebase this PR.