Bump chrono from 0.4.26 to 0.4.30 (#2755)

Bumps [chrono](https://github.com/chronotope/chrono) from 0.4.26 to
0.4.30.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/chronotope/chrono/releases">chrono's
releases</a>.</em></p>
<blockquote>
<h2>0.4.30</h2>
<p>In this release, we have decided to swap out the
<code>chrono::Duration</code> type (which has been a re-export of time
0.1 <code>Duration</code> type) with our own definition, which exposes a
strict superset of the <code>time::Duration</code> API. This helps avoid
warnings about the <a
href="https://nvd.nist.gov/vuln/detail/CVE-2020-26235">CVE-2020-26235</a>
and <a
href="https://rustsec.org/advisories/RUSTSEC-2020-0071">RUSTSEC-2020-0071</a>
advisories for downstream users and allows us to improve the
<code>Duration</code> API going forward.</p>
<p>While this is technically a SemVer-breaking change, we expect the
risk of downstream users experiencing actual incompatibility to be
exceedingly limited (see <a
href="https://redirect.github.com/chronotope/chrono/pull/1095#issuecomment-1571716955">our
analysis</a> of public code using a crater-like experiment), and not
enough justification for the large ecosystem churn of a 0.5 release. If
you have any feedback on these changes, please let us know in <a
href="https://redirect.github.com/chronotope/chrono/issues/1268">#1268</a>.</p>
<h3>Additions</h3>
<ul>
<li>Add <code>NaiveDate::leap_year</code> (<a
href="https://redirect.github.com/chronotope/chrono/issues/1261">#1261</a>)</li>
</ul>
<h3>Documentation</h3>
<ul>
<li>Update main documentation from README (<a
href="https://redirect.github.com/chronotope/chrono/issues/1260">#1260</a>,
thanks <a
href="https://github.com/Stygmates"><code>@​Stygmates</code></a>)</li>
<li>Add history of relation between chrono and time 0.1 to documentation
(<a
href="https://redirect.github.com/chronotope/chrono/pull/1264">chronotope/chrono#1264</a>,
<a
href="https://redirect.github.com/chronotope/chrono/pull/1266">chronotope/chrono#1266</a>)</li>
<li>Clarify <code>Timelike::num_seconds_from_midnight</code> is a simple
mapping (<a
href="https://redirect.github.com/chronotope/chrono/issues/1255">#1255</a>)</li>
</ul>
<h2>Relation between chrono and time 0.1</h2>
<p>Rust first had a <code>time</code> module added to <code>std</code>
in its 0.7 release. It later moved to <code>libextra</code>, and then to
a <code>libtime</code> library shipped alongside the standard library.
In 2014 work on chrono started in order to provide a full-featured date
and time library in Rust. Some improvements from chrono made it into the
standard library; notably, <code>chrono::Duration</code> was included as
<code>std::time::Duration</code> (<a
href="https://redirect.github.com/rust-lang/rust/pull/15934">rust#15934</a>)
in 2014.</p>
<p>In preparation of Rust 1.0 at the end of 2014 <code>libtime</code>
was moved out of the Rust distro and into the <code>time</code> crate to
eventually be redesigned (<a
href="https://redirect.github.com/rust-lang/rust/pull/18832#issuecomment-62448221">rust#18832</a>,
<a
href="https://redirect.github.com/rust-lang/rust/pull/18858">rust#18858</a>),
like the <code>num</code> and <code>rand</code> crates. Of course chrono
kept its dependency on this <code>time</code> crate. <code>time</code>
started re-exporting <code>std::time::Duration</code> during this
period. Later, the standard library was changed to have a more limited
unsigned <code>Duration</code> type (<a
href="https://redirect.github.com/rust-lang/rust/pull/24920">rust#24920</a>,
<a href="https://rust-lang.github.io/rfcs/1040-duration-reform.html">RFC
1040</a>), while the <code>time</code> crate kept the full functionality
with <code>time::Duration</code>. <code>time::Duration</code> had been a
part of chrono's public API.</p>
<p>By 2016 <code>time</code> 0.1 lived under the
<code>rust-lang-deprecated</code> organisation and was not actively
maintained (<a
href="https://redirect.github.com/time-rs/time/issues/136">time#136</a>).
chrono absorbed the platform functionality and <code>Duration</code>
type of the <code>time</code> crate in <a
href="https://redirect.github.com/chronotope/chrono/pull/478">chrono#478</a>
(the work started in <a
href="https://redirect.github.com/chronotope/chrono/pull/286">chrono#286</a>).
In order to preserve compatibility with downstream crates depending on
<code>time</code> and <code>chrono</code> sharing a
<code>Duration</code> type, chrono kept depending on time 0.1. chrono
offered the option to opt out of the <code>time</code> dependency by
disabling the <code>oldtime</code> feature (swapping it out for an
effectively similar chrono type). In 2019, <a
href="https://github.com/jhpratt"><code>@​jhpratt</code></a> took over
maintenance on the <code>time</code> crate and released what amounts to
a new crate as <code>time</code> 0.2.</p>
<h3>Security advisories</h3>
<p>In November of 2020 <a
href="https://nvd.nist.gov/vuln/detail/CVE-2020-26235">CVE-2020-26235</a>
and <a
href="https://rustsec.org/advisories/RUSTSEC-2020-0071">RUSTSEC-2020-0071</a>
were opened against the <code>time</code> crate. <a
href="https://github.com/quininer"><code>@​quininer</code></a> had found
that calls to <code>localtime_r</code> may be unsound (<a
href="https://redirect.github.com/chronotope/chrono/pull/499">chrono#499</a>).
Eventually, almost a year later, this was also made into a security
advisory against chrono as <a
href="https://rustsec.org/advisories/RUSTSEC-2020-0159.html">RUSTSEC-2020-0159</a>,
which had platform code similar to <code>time</code>.</p>
<p>On Unix-like systems a process is given a timezone id or description
via the <code>TZ</code> environment variable. We need this timezone data
to calculate the current local time from a value that is in UTC, such as
the time from the system clock. <code>time</code> 0.1 and chrono used
the POSIX function <code>localtime_r</code> to do the conversion to
local time, which reads the <code>TZ</code> variable.</p>
<p>Rust assumes the environment to be writable and uses locks to access
it from multiple threads. Some other programming languages and libraries
use similar locking strategies, but these are typically not shared
across languages. More importantly, POSIX declares modifying the
environment in a multi-threaded process as unsafe, and
<code>getenv</code> in libc can't be changed to take a lock because it
returns a pointer to the data (see <a
href="https://redirect.github.com/rust-lang/rust/issues/27970">rust#27970</a>
for more discussion).</p>
<p>Since version 4.20 chrono no longer uses <code>localtime_r</code>,
instead using Rust code to query the timezone (from the <code>TZ</code>
variable or via <code>iana-time-zone</code> as a fallback) and work with
data from the system timezone database directly. The code for this was
forked from the <a href="https://crates.io/crates/tz-rs">tz-rs crate</a>
by <a href="https://github.com/x-hgg-x"><code>@​x-hgg-x</code></a>. As
such, chrono now respects the Rust lock when reading the <code>TZ</code>
environment variable. In general, code should avoid modifying the
environment.</p>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/chronotope/chrono/commit/101ca7e96d57ee751db2b44e6320ee1e06adeda0"><code>101ca7e</code></a>
Bump version to 0.4.30</li>
<li><a
href="https://github.com/chronotope/chrono/commit/eee59e373aced18381be25a7a354ee695aba7338"><code>eee59e3</code></a>
Rewrite history sections for clarity and consistency</li>
<li><a
href="https://github.com/chronotope/chrono/commit/7387fe7aba675f3d37cf24239e038cdd66636233"><code>7387fe7</code></a>
Add history of chrono and time 0.1 to main documentation</li>
<li><a
href="https://github.com/chronotope/chrono/commit/8509da4979db0adca872b21752e52969746428fa"><code>8509da4</code></a>
Apply Clippy suggestions for duration module</li>
<li><a
href="https://github.com/chronotope/chrono/commit/9d7fafe69b56aa1d79e6070ebb5cdecdacee85c6"><code>9d7fafe</code></a>
Remove mention of <code>oldtime</code> from documentation</li>
<li><a
href="https://github.com/chronotope/chrono/commit/27ea7e90073466032cbce08c5a3f340c38d66fe2"><code>27ea7e9</code></a>
Rename <code>oldtime</code> module to <code>duration</code></li>
<li><a
href="https://github.com/chronotope/chrono/commit/8f5becd2774daabb172ea846fd5e5a0e192461f5"><code>8f5becd</code></a>
Drop time 0.1 as optional dependency</li>
<li><a
href="https://github.com/chronotope/chrono/commit/f4aefc7f3359be30d9b391277197c06dddc2cab0"><code>f4aefc7</code></a>
Clarify <code>Timelike::num_seconds_from_midnight</code> is a simple
mapping</li>
<li><a
href="https://github.com/chronotope/chrono/commit/1903778a1529761e72c6d201ef034cd17ca5e6b4"><code>1903778</code></a>
Add NaiveDate::leap_year</li>
<li><a
href="https://github.com/chronotope/chrono/commit/84334df989db941be889c59678379becde4d17cf"><code>84334df</code></a>
Update readme</li>
<li>Additional commits viewable in <a
href="https://github.com/chronotope/chrono/compare/v0.4.26...v0.4.30">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=chrono&package-manager=cargo&previous-version=0.4.26&new-version=0.4.30)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

src/core/Cargo.toml

@@ -83,7 +83,7 @@ version = "0.3.64"
 features = ["console", "File"]
 
 [target.'cfg(all(target_arch = "wasm32"))'.dependencies.chrono]
-version = "0.4.26"
+version = "0.4.30"
 features = ["wasmbind"]
 
 [target.'cfg(all(target_arch = "wasm32", target_os="unknown"))'.dev-dependencies]