Skip to content

Releases: chronotope/chrono

v0.4.0

05 Sep 12:02
fe529c8
Compare
Choose a tag to compare

Original annoucement: https://users.rust-lang.org/t/chrono-0-4-0-is-out/11466.

The new version of Chrono, the date and time library for Rust, has been released.

This version fixes the dependency issues raised in 0.3.1 (in lieu of this release, 0.3.1 is now yanked as well) while moving towards the more idiomatic API convention. This version was developed in relatively heavy time constraints, but I have managed to include several goodies:

  • DateTime types can now be serialized to, or deserialized from the integral UNIX timestamp.
  • DateTime types and std::time::SystemTime can be freely converted back and forth via From.
  • IsoWeek type has been introduced.
  • The documentation has been streamlined by removing intermediate implementation modules and accounting for several minor but essential suggestions.

This was originally planned as a minor release but was pushed to a major release due to the compatibility concern raised.

Added

  • IsoWeek has been added for the ISO week without time zone.

  • The += and -= operators against time::Duration are now supported for NaiveDate, NaiveTime and NaiveDateTime. (#99)

    (Note that this does not invalidate the eventual deprecation of time::Duration.)

  • SystemTime and DateTime<Tz> types can be now converted to each other via From. Due to the obvious lack of time zone information in SystemTime, the forward direction is limited to DateTime<Utc> and DateTime<Local> only.

Changed

  • Intermediate implementation modules have been flattened (#161), and UTC has been renamed to Utc in accordance with the current convention (#148).

    The full list of changes is as follows:

    Before After
    chrono::date::Date chrono::Date
    chrono::date::MIN chrono::MIN_DATE
    chrono::date::MAX chrono::MAX_DATE
    chrono::datetime::DateTime chrono::DateTime
    chrono::naive::time::NaiveTime chrono::naive::NaiveTime
    chrono::naive::date::NaiveDate chrono::naive::NaiveDate
    chrono::naive::date::MIN chrono::naive::MIN_DATE
    chrono::naive::date::MAX chrono::naive::MAX_DATE
    chrono::naive::datetime::NaiveDateTime chrono::naive::NaiveDateTime
    chrono::offset::utc::UTC chrono::offset::Utc
    chrono::offset::fixed::FixedOffset chrono::offset::FixedOffset
    chrono::offset::local::Local chrono::offset::Local
    chrono::format::parsed::Parsed chrono::format::Parsed

    With an exception of Utc, this change does not affect any direct usage of chrono::* or chrono::prelude::* types.

  • Datelike::isoweekdate is replaced by Datelike::iso_week which only returns the ISO week.

    The original method used to return a tuple of year number, week number and day of the week, but this duplicated the Datelike::weekday method and it had been hard to deal with the raw year and week number for the ISO week date. This change isolates any logic and API for the week date into a separate type.

  • NaiveDateTime and DateTime can now be deserialized from an integral UNIX timestamp. (#125)

    This turns out to be very common input for web-related usages. The existing string representation is still supported as well.

  • chrono::serde and chrono::naive::serde modules have been added for the serialization utilities. (#125)

    Currently they contain the ts_seconds modules that can be used to serialize NaiveDateTime and DateTime values into an integral UNIX timestamp. This can be combined with Serde's [de]serialize_with attributes to fully support the (de)serialization to/from the timestamp.

    For rustc-serialize, there are separate chrono::TsSeconds and chrono::naive::TsSeconds types that are newtype wrappers implementing different (de)serialization logics. This is a suboptimal API, however, and it is strongly recommended to migrate to Serde.

Fixed

  • The major version was made to fix the broken Serde dependency issues. (#146, #156, #158, #159)

    The original intention to technically break the dependency was to facilitate the use of Serde 1.0 at the expense of temporary breakage. Whether this was appropriate or not is quite debatable, but it became clear that there are several high-profile crates requiring Serde 0.9 and it is not feasible to force them to use Serde 1.0 anyway.

    To the end, the new major release was made with some known lower-priority breaking changes. 0.3.1 is now yanked and any remaining 0.3 users can safely roll back to 0.3.0.

  • Various documentation fixes and goodies. (#92, #131, #136)

v0.3.1

05 Sep 12:03
dcf1933
Compare
Choose a tag to compare

Added

  • Weekday now implements FromStr, Serialize and Deserialize. (#113)

    The syntax is identical to %A, i.e. either the shortest or the longest form of English names.

Changed

  • Serde 1.0 is now supported. (#142)

    This is technically a breaking change because Serde 0.9 and 1.0 are not compatible, but this time we decided not to issue a minor version because we have already seen Serde 0.8 and 0.9 compatibility problems even after 0.3.0 and a new minor version turned out to be not very helpful for this kind of issues.

Fixed

  • Fixed a bug that the leap second can be mapped wrongly in the local time zone. Only occurs when the local time zone is behind UTC. (#130)

Note that the actually published version is very slightly different from the repository because no published version of bincode supports Serde 1.0 right now.

v0.3.0

05 Sep 12:05
db9b98f
Compare
Choose a tag to compare

Original announcement: https://users.rust-lang.org/t/chrono-0-3-released-and-the-future/9340

So Chrono 0.3.0, a much delayed major version of Rust date and time library, is here. Update and watch your build breaking Enjoy.

Breaking Changes

I have described all changes to the changelog but the recent issue seems to indicate that it is not enough. So the following is the list of breaking changes primarily relevant to the users.

  • Rust 1.13.0 or later is required.

    As we have moved to Serde 0.9, we have bumped the minimal supported version to 1.13.0. It is possible to use Chrono on older versions with or without Serde (previously 1.8.0 was the minimal, and Serde 0.9 seems to work well with 1.12.0) but they are no longer supported now.

  • The subtraction between two time instants/points is gone.

    You should use a.signed_duration_since(b) instead of a - b. As you can expect, this name is very similar to the standard library's one, but returns time::Duration instead of std::time::Duration. The proper name, duration_since has been reserved for the transition.

    (As aside, I don't think that the subtraction operator in this case will return. It is very awkward to return Result<Duration, NegativeDuration> from an operator, and risking the panic every time one subtract two normal points seems to be unreasonable.)

    I don't know if these methods are used a lot, but checked_{add,sub} and overflowing_{add,sub} methods had met the same fate: They are now called checked_{add,sub}_signed and overflowing_{add,sub}_signed, respectively. The older names are reserved for the transition.

  • Rustc-serialize support is now exactly identical to the counterpart for Serde.

    Previously two implementations didn't agree to each other primarily because they are written by different contributors. Now they standardize on the std::fmt::Debug output, previously used by Serde implementations. This will cause the format change if you are using rustc-serialize to read and write a long lasting format, so you should be prepared for it.

    Rustc-serialize implementations actually covered more types than Serde in the past. They are now removed---more specifically, Date<Tz> and all offset types (DateTime<Tz> support is rewritten per each Tz). While it is not very trivial to reintroduce them in a sane manner, this removal should be considered temporary.

Near Future

This release contains lots of other minor breaking changes to allow more changes without breaking the compatibility. (Many fixes were blocked by them, for instance.)

The most significant one is that we no longer use Duration (that is, time::Duration) for representing the time zone offset. It might sound strange but Offset is the "storage" offset type and Offset::local_minus_utc used to return the Duration for the offset "value". Now the offset
"value" is represented by FixedOffset (which is also a stroage type by its own), which has a good side effect that the offset is guaranteed to be within one day. In my experience this was a single biggest problem in implementing advanced time zone support---I expect this can be done much better by now.

We have also sorted out any types that were too public to be extended without breaking changes.
For 0.3.0 they consist solely of formatting types, and they have received a private (dummy) field
for the future expansion. We can now extend formatting (privately) without breaking public interfaces.

Far Future

There are two major concerns in the far future (I mean, next year or so) of Chrono.

First, Chrono will become a community project at last. I had initiated and maintained the project so far, but in the last year (2016) I had significant energy depletion that has prevented me to do anything that is not a daily job (as you may know, I also use Rust at work). Not that I think that the current version is good enough---I've resolved many required breaking changes I was aware of during the 0.3.0 release for example.

The Chronotope organization is, I think, the major step towards the community project, but that is not enough. I have reserved it in the past, but I invite you to #chronotope IRC channel at irc.mozilla.org. Also I'm willing to invite more contributors and relevant projects to the
organization (chrono-tz comes to my mind). I'm not sure how to start but having a venue for the discussion could be a good start.

Second, Chrono will set the official relationship to the standard library types. std::time::Duration support is the beginning, and what I'm most concerned is std::time::SystemTime.

In the past I thought that the time library will be kept as is and Chrono will fill the niche gap. The situation has changed—SystemTime no longer concerns about the calendar time. This means that the Chrono date and time types should be a canonical type for the calendar time while also filling the niche. This discrepancy was a source of design issues:

  • People seems to use DateTime<Tz> as a primary storage type, rather than as an alternative type used for formatting and calculation.

  • While it is designed to be much faster than alternatives, Chrono's main representation still is a calendar time and causes overhead when you don't need that. SystemTime::now() is at least 10x faster than UTC::now().

  • The TimeZone type parameter is a source of many complaints. The original design was selected so that we don't have to deal with the synchronization or sharing issue, and also we can get the needed information for date and time calculation, but my observation is that calculation is less used than formatting.

There are several approaches to solve them, and I have one particular approach in mind—removing a TimeZone parameter at all and delegating all tz-aware operation to the external object. The alternative datetime library seems to explore another possibiltiy (to make the time zone object internal) as well. No matter which design is selected, I believe this needs many eyes to perfect, and want to gather users' feedback as well.


The project has moved to the Chronotope organization.

Added

  • chrono::prelude module has been added. All other glob imports are now discouraged.

  • FixedOffset can be added to or subtracted from any timelike types.

    • FixedOffset::local_minus_utc and FixedOffset::utc_minus_local methods have been added. Note that the old Offset::local_minus_utc method is gone; see below.
  • Serde support for non-self-describing formats like Bincode is added. (#89)

  • Added Item::Owned{Literal,Space} variants for owned formatting items. (#76)

  • Formatting items and the Parsed type have been slightly adjusted so that they can be internally extended without breaking any compatibility.

  • Weekday is now Hashable. (#109)

  • ParseError now implements Eq as well as PartialEq. (#114)

  • More documentation improvements. (#101, #108, #112)

Changed

  • Chrono now only supports Rust 1.13.0 or later (previously: Rust 1.8.0 or later).

  • Serde 0.9 is now supported. Due to the API difference, support for 0.8 or older is discontinued. (#122)

  • Rustc-serialize implementations are now on par with corresponding Serde implementations.
    They both standardize on the std::fmt::Debug textual output.

    This is a silent breaking change (hopefully the last though).
    You should be prepared for the format change if you depended on rustc-serialize.

  • Offset::local_minus_utc is now Offset::fix, and returns FixedOffset instead of a duration.

    This makes every time zone operation operate within a bias less than one day, and vastly simplifies many logics.

  • chrono::format::format now receives FixedOffset instead of time::Duration.

  • The following methods and implementations have been renamed and older names have been removed.
    The older names will be reused for the same methods with std::time::Duration in the future.

    • checked_*checked_*_signed in Date, DateTime, NaiveDate and NaiveDateTime types

    • overflowing_*overflowing_*_signed in the NaiveTime type

    • All subtraction implementations between two time instants have been moved to signed_duration_since, following the naming in std::time.

Fixed

  • Fixed a panic when the Local offset receives a leap second. (#123)

Removed

  • Rustc-serialize support for Date<Tz> types and all offset types has been dropped.

    These implementations were automatically derived and never had been in a good shape.
    Moreover there are no corresponding Serde implementations, limiting their usefulness.
    In the future they may be revived with more complete implementations.

  • The following method aliases deprecated in the 0.2 branch have been removed.

    • DateTime::num_seconds_from_unix_epoch (→ DateTime::timestamp)
    • NaiveDateTime::from_num_seconds_from_unix_epoch (→ NaiveDateTime::from_timestamp)
    • NaiveDateTime::from_num_seconds_from_unix_epoch_opt (→ NaiveDateTime::from_timestamp_opt)
    • NaiveDateTime::num_seconds_unix_epoch (→ NaiveDateTime::timestamp)
  • Formatting items are no longer Copy, except for chrono::format::Pad.

  • chrono::offset::add_with_leapsecond has been removed.
    Use a direct addition with FixedOffset instead.

v0.2.25

05 Sep 12:06
Compare
Choose a tag to compare

This is the last version officially supports Rust 1.12.0 or older.

(0.2.24 was accidentally uploaded without a proper check for warnings in the default state,
and replaced by 0.2.25 very shortly. Duh.)

v0.2.24

05 Sep 12:06
Compare
Choose a tag to compare

Added

  • Serde 0.8 is now supported. 0.7 also remains supported. (#86)

Fixed

  • The deserialization implementation for rustc-serialize now properly verifies the input.
    All serialization codes are also now thoroughly tested. (#42)

v0.2.23

05 Sep 12:07
Compare
Choose a tag to compare

Added

  • The documentation was greatly improved for several types, and tons of cross-references have been added. (#77, #78, #80, #82)

  • DateTime::timestamp_subsec_{millis,micros,nanos} methods have been added. (#81)

Fixed

  • When the system time records a leap second, the nanosecond component was mistakenly reset to zero. (#84)

  • Local offset misbehaves in Windows for August and later, due to the long-standing libtime bug (dates back to mid-2015).
    Workaround has been implemented. (#85)

v0.2.22

05 Sep 12:07
Compare
Choose a tag to compare

Fixed

  • %.6f and %.9f used to print only three digits when the nanosecond part is zero. (#71)
  • The documentation for %+ has been updated to reflect the current status. (#71)

v0.2.21

05 Sep 12:08
Compare
Choose a tag to compare

Fixed

  • Fixed::LongWeekdayName was unable to recognize "sunday" (whoops). (#66)

v0.2.20

05 Sep 12:08
Compare
Choose a tag to compare

Changed

  • serde dependency has been updated to 0.7. (#63, #64)

v0.2.19

05 Sep 12:09
Compare
Choose a tag to compare

Added

  • The documentation for Date is made clear about its ambiguity and guarantees.

Fixed

  • DateTime::date had been wrong when the local date and the UTC date is in disagreement. (#61)