-
Notifications
You must be signed in to change notification settings - Fork 2
Update Rust crate chrono to 0.4.42 #72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
renovate
wants to merge
1
commit into
main
Choose a base branch
from
renovate/chrono-0.x
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5cc7652 to
d52db6c
Compare
d52db6c to
bdf9ae4
Compare
bdf9ae4 to
35e4896
Compare
8e011b1 to
799c5ef
Compare
799c5ef to
6147a31
Compare
b63683d to
0866084
Compare
0866084 to
98e7d04
Compare
98e7d04 to
993810a
Compare
993810a to
06c3cd3
Compare
06c3cd3 to
47d3ee8
Compare
47d3ee8 to
0d043ea
Compare
0d043ea to
dbbd359
Compare
dbbd359 to
34f6fae
Compare
34f6fae to
c67e0be
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
Test plan: CI should pass with updated dependencies. No review required: this is an automated dependency update PR.
Release Notes
chronotope/chrono (chrono)
v0.4.42: 0.4.42Compare Source
What's Changed
wasm32-linuxsupport by @arjunr2 in #1707tzdataparsing by @ldm0 in #1679?Sizedbound to related methods ofDelayedFormat::write_toby @Huliiiiii in #1721from_timestamp_secsmethod toDateTimeby @jasonaowen in #1719v0.4.41Compare Source
What's Changed
subsec_microsandsubsec_millismethods toTimeDeltaby @ggoetz in #1668NaiveDateTime::UNIX_EPOCHby @robertbastian in #1670as_seconds_f32andas_seconds_f64forTimeDeltaby @ggoetz in #1671num_days_in_monthmethod toDateliketrait by @aslilac in #1673WeekdaySet, a collection ofWeekdaythat isCopyby @Kinrany in #1676v0.4.40: 0.4.40Compare Source
What's Changed
write_toforDelayedFormatby @tugtugtug in #1654v0.4.39: 0.4.39Compare Source
What's Changed
from_timestamp_nanos()by @sgoll in #1591NaiveWeekmethods by @bragov4ik in #1600PartialEq,Eq,Hash,CopyandCloneonNaiveWeekby @DSeeLP in #1618#[inline]tonum_daysby @CommanderStorm in #1627v0.4.38Compare Source
This release bring a ca. 20% improvement to the performance of the formatting code, and a convenient
days_sincemethod for theWeekdaytype.Chrono 0.4.38 also removes the long deprecated
rustc-serializefeature. Support forrustc-serializewill be soft-destabilized in the next Rust edition. Removing the feature will not break existing users of the feature; Cargo will just not update dependents that rely on it to newer versions of chrono.In chrono 0.4.36 we made an accidental breaking change by switching to
derive(Copy)forDateTimeinstead of a manual implementation. It is reverted in this release.Removals
rustc-serializefeature (#1548, thanks @workingjubilee)Additions
Weekday::days_since(#1249, based on #216 by @clarfonthey)TimeDelta::checked_mulandTimeDelta::checked_div(#1565, thanks @Zomtir)Fixes
CopyforDateTimeif offset isCopy(#1573)Internal
test_encodable_jsonandtest_decodable_jsonfunctions (#1550)cargo hack check(#1553)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.37Compare Source
Version 0.4.36 introduced an unexpected breaking change and was yanked. In it
LocalResultwas renamed toMappedLocalTimeto avoid the impression that it is aResulttype were some of the results are errors. For backwards compatibility a type alias with the old name was added.As it turns out there is one case where a type alias behaves differently from the regular enum: you can't import enum variants from a type alias with
use chrono::LocalResult::*. With 0.4.37 we make the new nameMappedLocalTimethe alias, but keep using it in function signatures and the documentation as much as possible.See also the release notes of chrono 0.4.36 from yesterday for the yanked release.
v0.4.36Compare Source
This release un-deprecates the methods on
TimeDeltathat were deprecated with the 0.4.35 release because of the churn they are causing for the ecosystem.New is the
DateTime::with_time()method. As an example of when it is useful:Additions
DateTime::with_time()(#1510)Deprecations
TimeDeltadeprecations (#1543)TimeStamp::timestamp_subsec_nanos, which was missed in the 0.4.35 release (#1486)Documentation
Internal
CopyandSendimpls (#1492, thanks @erickt)NaiveDateunit tests (#1500, thanks @Zomtir)LocalResulttoTzResolution, add alias (#1501)NaiveDate::from_yof(#1518)DateTime::date_naiveandNaiveDate::diff_months(#1530)unwrapin UnixLocaltype (#1533)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.35Compare Source
Most of our efforts have shifted to improving the API for a 0.5 release, for which cleanups and refactorings are landing on the 0.4.x branch.
The most significant changes in this release are two sets of deprecations.
We deprecated all timestamp-related methods on
NaiveDateTime. The reason is that a timestamp is defined to be in UTC. TheNaiveDateTimetype doesn't know the offset from UTC, so it was technically wrong to have these methods. The alternative is to use the similar methods on theDateTime<Utc>type, or from theTimeZonetrait.Converting from
NaiveDateTimetoDateTime<Utc>is simple with.and_utc(), and in the other direction with.naive_utc().The panicking constructors of
TimeDelta(the new name of theDurationtype) are deprecated. This was the last part of chrono that defaulted to panicking on error, dating from before rust 1.0.A nice change is that
NaiveDatenow includes a niche. So nowOption<NaiveDate>,Option<NaiveDateTime>andOption<DateTime<Tz>>are the same size as their base types.format::Numericandformat::Fixedare marked asnon_exhaustive. This will allow us to improve our formatting and parsing support, and we have reason to believe this breaking change will have little to no impact on users.Additions
DateTime::{from_timestamp_micros, from_timestamp_nanos}(#1234)Parsed(#1465)Deprecations
NaiveDateTime(#1473)TimeDelta(#1450)Changes/fixes
NonZeroI32insideNaiveDate(#1207)format::Numericandformat::Fixedasnon_exhaustive(#1430)Parsedfixes to error values (#1439)overflowing_naive_localinDateTime::checked_add*(#1333)Parsed::set_*(#1465)Documentation
Parsed(#1439)Internal
internalsmodule (#1428, #1429, #1431, #1432, #1433, #1438)x86_64-unknown-illumosinstead of Solaris (#1437)cargo hack checkon Linux (#1442)parse_internal(#1459)SerdeError(#1458)NaiveDate::from_isoywda bit (#1464)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.34Compare Source
Notable changes
Durationtype toTimeDelta. This removes the confusion between chrono's type and the laterDurationtype in the standard library. It will remain available under the old name as a type alias for compatibility.Localis rewritten. The new version avoids panics when the date is outside of the range supported by windows (the years 1601 to 30828), and gives more accurate results during DST transitions.Displayformat ofTimeDeltais modified to conform better to ISO 8601. Previously it converted all values greater than 24 hours to a value with days. This is not correct, as doing so changes the duration from an 'accurate' to a 'nominal' representation to use ISO 8601 terms.Fixes
TimeDelta::milliseconds(#1385, thanks @danwilliams)DurationExceedsTimestampinDurationRound(#1403, thanks @joroKr21)%X(chronotope/pure-rust-locales#12, #1420)GetTimeZoneInformationForYear(#1017)Additions
TimeDelta::try_milliseconds(#1385, thanks @danwilliams)TimeDelta::new(#1337)StrftimeItems::{parse, parse_to_owned}and more documentation (#1184)format::Locale(via chronotope/pure-rust-locales#8)Changes
DurationtoTimeDelta, add type alias (#1406)TimeDeltamethods const (#1337)NaiveDate,NaiveWeek,NaiveTimeandNaiveDateTimeconst where possible (#1337)DateTimeconst where possible (#1400)Displayformat ofTimeDeltaconform better to ISO 8601 (#1328)Documentation
timestamp_micros's Example doc (#1338 via #1386, thanks @emikitas)TimeDeltaconstructors (#1385, thanks @danwilliams)Internal
mainbranch, work on 0.5 happens in the0.5.xbranch (#1390, #1402).impl Arbitrary for DateTimeand set up CI test (#1336)codecov/codecov-actionfrom 3 to 4 (#1404)-0000offset (#1411)TOO_LONGerror out ofparse_internal(#1419)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.33Compare Source
This release fixes the broken docrs.rs build of chrono 0.4.32.
What's Changed
rkyvfeature implysize_32(#1383)Duration::hours()exception (#1384, thanks @danwilliams)v0.4.32Compare Source
In this release we shipped part of the effort to reduce the number of methods that could unexpectedly panic, notably for the
DateTimeandDurationtypes.Chrono internally stores the value of a
DateTimein UTC, and transparently converts it to the local value as required. For example adding a second to aDateTimeneeds to be done in UTC to get the correct result, but adding a day needs to be done in local time to be correct. What happens when the value is near the edge of the representable range, and the implicit conversions pushes it beyond the representable range? Many methods could panic on such inputs, including formatting the value forDebugoutput.In chrono 0.4.32 the range of
NaiveDate,NaiveDateTimeandDateTimeis made slightly smaller. This allows us to always do the implicit conversion, and in many cases return the expected result. Specifically the range is now from January 1, -262144 until December 31, 262143, one year less on both sides than before. We expect this may trip up tests if you hardcoded theMINandMAXdates.Durationhad a similar issue. The range of this type was pretty arbitrary picked to match the range of ani64in milliseconds. Negating ani64::MINpushes a value out of range, and in the same way negatingDuration::MINcould push it out of our defined range and cause a panic. This turns out to be somewhat common and hidden behind many layers of abstraction. We adjusted the type to have a minimum value of-Duration::MAXinstead and prevent the panic case.Other highlights:
Durationgained new fallible initialization methods.rkyv.NaiveDateTimeare now const.DateTimeconst in a future release.Complete list of changes:
Fixes
TimeZone::from_local_datetime(#1071)DateTimegetters and setters (#1317, #1329)Additions
NaiveDateTime::checked_(add|sub)_offset(#1313)DateTime::to_utc(#1325)DefaultforDuration(#1327)Duration::subsec_nanos(#1327)try_*builders toDuration(#1327)AddAssignandSubAssignforDuration(#1327)NaiveDateTimeconst where possible (#1286)clockfeature intoclockandnow(#1343, thanks @mmastrac)From<NaiveDate>forNaiveDateTime(#1355, thanks @dcechano)NaiveDateTime::from_timestamp_nanos(#1357, thanks @Ali-Mirghasemi)Months::num_months()andnum_years()(#1373, thanks @danwilliams)DateTime<Utc>::from_timestamp_millis(#1374, thanks @xmakro)Changes
Duration::MIN.abs()(adjustDuration::MINby 1 millisecond) (#1334)Deprecations
formatfunctions (#1306)Documentation
doc_auto_cfg(#1305, #1326)Add/Subimpls and useexpect(#1316)TimeZone::datetime_from_str(#1342, thanks @tmccombs)Datelikeimpl forDateTime(#1376, thanks @ElectrifyPro)Rkyv support
Archived*types inrkyvmodule (#1304)Archived*types (#1271, thanks @Awpteamoose)Changes to unstable features
unstable-localesimply theallocfeature (#1307)format::{format_localized, format_item_localized}(#1311)write_rfc2822_inner, don't localize (#1322)Internal
DateTime::with_*(#1309)*_DAYS_FROM_YEAR_0calculation (#1312)NaiveTime::overflowing_(add|sub)_offset(#1310)DateTime::overflowing_(add|sub)_offset(#1069)set env LC_ALL(#1315, thanks @jtmoon79)deny.toml(#1320)with: node-version(#1352, thanks @jtmoon79)tomljob (#1371, thanks @gibbz00)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.31Compare Source
Another maintenance release.
It was not a planned effort to improve our support for UNIX timestamps, yet most PRs seem related to this.
Deprecations
timestamp_nanosin favor of the non-panickingtimestamp_nanos_opt(#1275)Additions
DateTime::<Utc>::from_timestamp(#1279, thanks @demurgos)TimeZone::timestamp_micros(#1285, thanks @emikitas)DateTime<Tz>::timestamp_nanos_optandNaiveDateTime::timestamp_nanos_opt(#1275)UNIX_EPOCHconstants (#1291)Fixes
This makes many methods a little more strict:
NaiveTime::from_hms_milliNaiveTime::from_hms_milli_optNaiveTime::from_hms_microNaiveTime::from_hms_micro_optNaiveTime::from_hms_nanoNaiveTime::from_hms_nano_optNaiveTime::from_num_seconds_from_midnightNaiveTime::from_num_seconds_from_midnight_optNaiveDate::and_hms_milliNaiveDate::and_hms_milli_optNaiveDate::and_hms_microNaiveDate::and_hms_micro_optNaiveDate::and_hms_nanoNaiveDate::and_hms_nano_optNaiveDateTime::from_timestampNaiveDateTime::from_timestamp_optTimeZone::timestampTimeZone::timestamp_optNaiveDateTime::timestamp_nanos_opt(#1294, thanks @crepererum)Documentation
Internal
__doctestfeature anddoc_commentdependency (#1276)actions/checkoutfrom 3 to 4 (#1280)NaiveDate::add_daysfor small values (#1214)pure-rust-localesto 0.7.0 (#1288, thanks @jeremija wo did good improvements onpure-rust-locales)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.30Compare Source
In this release, we have decided to swap out the
chrono::Durationtype (which has been a re-export of time 0.1Durationtype) with our own definition, which exposes a strict superset of thetime::DurationAPI. This helps avoid warnings about the CVE-2020-26235 and RUSTSEC-2020-0071 advisories for downstream users and allows us to improve theDurationAPI going forward.While this is technically a SemVer-breaking change, we expect the risk of downstream users experiencing actual incompatibility to be exceedingly limited (see our analysis 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 #1268.
Additions
NaiveDate::leap_year(#1261)Documentation
Timelike::num_seconds_from_midnightis a simple mapping (#1255)Relation between chrono and time 0.1
Rust first had a
timemodule added tostdin its 0.7 release. It later moved tolibextra, and then to alibtimelibrary 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,chrono::Durationwas included asstd::time::Duration(rust#15934) in 2014.In preparation of Rust 1.0 at the end of 2014
libtimewas moved out of the Rust distro and into thetimecrate to eventually be redesigned (rust#18832, rust#18858), like thenumandrandcrates. Of course chrono kept its dependency on thistimecrate.timestarted re-exportingstd::time::Durationduring this period. Later, the standard library was changed to have a more limited unsignedDurationtype (rust#24920, RFC 1040), while thetimecrate kept the full functionality withtime::Duration.time::Durationhad been a part of chrono's public API.By 2016
time0.1 lived under therust-lang-deprecatedorganisation and was not actively maintained (time#136). chrono absorbed the platform functionality andDurationtype of thetimecrate in chrono#478 (the work started in chrono#286). In order to preserve compatibility with downstream crates depending ontimeandchronosharing aDurationtype, chrono kept depending on time 0.1. chrono offered the option to opt out of thetimedependency by disabling theoldtimefeature (swapping it out for an effectively similar chrono type). In 2019, @jhpratt took over maintenance on thetimecrate and released what amounts to a new crate astime0.2.Security advisories
In November of 2020 CVE-2020-26235 and RUSTSEC-2020-0071 were opened against the
timecrate. @quininer had found that calls tolocaltime_rmay be unsound (chrono#499). Eventually, almost a year later, this was also made into a security advisory against chrono as RUSTSEC-2020-0159, which had platform code similar totime.On Unix-like systems a process is given a timezone id or description via the
TZenvironment 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.time0.1 and chrono used the POSIX functionlocaltime_rto do the conversion to local time, which reads theTZvariable.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
getenvin libc can't be changed to take a lock because it returns a pointer to the data (see rust#27970 for more discussion).Since version 4.20 chrono no longer uses
localtime_r, instead using Rust code to query the timezone (from theTZvariable or viaiana-time-zoneas a fallback) and work with data from the system timezone database directly. The code for this was forked from the tz-rs crate by @x-hgg-x. As such, chrono now respects the Rust lock when reading theTZenvironment variable. In general, code should avoid modifying the environment.Removing time 0.1
Because time 0.1 has been unmaintained for years, however, the security advisory mentioned above has not been addressed. While chrono maintainers were careful not to break backwards compatibility with the
time::Durationtype, there has been a long stream of issues from users inquiring about the time 0.1 dependency with the vulnerability. We investigated the potential breakage of removing the time 0.1 dependency in chrono#1095 using a crater-like experiment and determined that the potential for breaking (public) dependencies is very low. We reached out to those few crates that did still depend on compatibility with time 0.1.As such, for chrono 0.4.30 we have decided to swap out the time 0.1
Durationimplementation for a local one that will offer a strict superset of the existing API going forward. This will prevent most downstream users from being affected by the security vulnerability in time 0.1 while minimizing the ecosystem impact of semver-incompatible version churn.Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.29Compare Source
This release fixes a panic introduced in chrono 0.4.27 in
FromStr<DateTime<Utc>>(#1253).Chrono now has a Discord channel.
Fixes
parse_rfc3339_relaxed(#1254)Deprecations
TimeZone::datetime_from_str(#1251)Documentation
FromStrforWeekdayandMonth(#1226, thanks @wfraser)Internal improvements
i686andwasm32-wasi(#1237)This allows us to upgrade the criterion dependency to 5.1 without changing our MSRV.
Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.28Compare Source
This release fixes a test failure on 32-bit targets introduced with 0.4.27, see #1234.
v0.4.27Compare Source
This release bumps the MSRV from 1.56 to 1.57. This allows us to take advantage of the panicking in const feature. In this release most methods on
NaiveDateandNaiveTimeare made const,NaiveDateTimeand others will follow in a later release.The parser for the
%+formatting specifier and theRFC3339formatting item is switched from a strict to a relaxed parser (see #1145). This matches the existing documentation, and the parser used byDateTime::from_str. If you need to validate the input, consider usingDateTime::from_rfc3339.Deprecations
DateTime::{from_local, from_utc}(#1175)Additions
DateTime::signed_duration_sincetake argument withBorrow(#1119)PartialOrdforMonth(#999, thanks @Munksgaard)OrdandEqfor types which already derivePartialOrdandPartialEq(#1128, thanks @totikom)FusedIteratorforNaiveDateDaysIteratorandNaiveDateWeeksIterator(#1134)NaiveDateDaysIteratorandNaiveDateWeeksIteratorpublic (#1134)FromStrforFixedOffset(#1157, thanks @mcronce)Tz::Offset: Displayrequirement fromDateTime::to_rfc*(#1160)StrftimeItemswithunstable-localeswork without allocating (#1152)NaiveDate::from_ymd_optconst (#1172, thanks @kamadorueda)Errortrait forParseWeekdayErrorandParseMonthError(#539, thanks @mike-kfed)NaiveTimeconst, update MSRV to 1.57 (#1080)NaiveDateconst (#1205)core::time::DurationonDateTimetypes (#1229)Fixes
timestamp_nanospanics on overflow in release builds (#1123)offset_from_local_datetimeforwasm_bindgen(#1131)%sto be a timestamp in UTC (#1136)%#z(#1140, thanks @domodwyer)%cand%r(#1165)unstable-localesfeature (#1168)Offset'sDebugimpl when serializingDateTime(#1035)NaiveTime::from_str(#1181)android-tzdataif theclockfeature is not enabled (#1220, thanks @AlexTMjugador)Documentation
NaiveTimedoc typo (#1146, thanks @zachs18)Datelike::with_*(#1199)Utc::nowandLocal::now(#1192)Weekday::num_days_from_monday(#1193)Internal improvements
DateTime::to_rfc_*optimizations (#1200)format/formatting.rs(#1156)saturating_abs(#1124)Makefile(#1133)wasm-bindgenfeaturConfiguration
📅 Schedule: Branch creation - "on the 1st through 7th day of the month" in timezone America/Los_Angeles, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.