notquiteamonad / date_time

date_time is a high-level Rust library for use in situations where precision beyond seconds is not necessary.

Hi, I'm notquiteamonad.

You can read about what I'm working on at notquiteamonad.com/now.

date_time's Issues

Add the ability to find the difference between DateTimes

See notquiteamonad/datetimekt#17

Add a toDays() method on Duration

See notquiteamonad/datetimekt#40 (issue) and notquiteamonad/datetimekt#41 (pull request)

Allow @ to be space instead in format for from_str on DateTimeTuple

Consider making space default formatting as I believe it's closer to ISO-8601

Add coverage upload to rust GitHub Action

Remove travis when complete.

Methods to add/subtract hours/minutes/seconds to/from a TimeTuple

Similar to #3

Ability to add/subtract multiple months/years from a MonthTuple

Methods such as add_years on MonthTuple to achieve these four goals

Add function for DateTuple to return the current date

Dependabot couldn't find the branch integration

Dependabot was set up to create pull requests against the branch integration, but couldn't find it.

If the branch has been permanently deleted you can update Dependabot's target branch from your dashboard.

You can mention @dependabot in the comments below to contact the Dependabot team.

Fix MonthTuple's serialisation to conform to ISO 8601

#16 was merged without checking it was applied to MonthTuple. This needs to be rectified.

Bring serialisation closer to ISO 8601

Legacy serialisation will still need to be supported for backwards compatibility, but a mixture of the two formats should not be accepted.

ISO 8601 for reference: https://www.iso.org/iso-8601-date-and-time-format.html

Certify to CII Best Practices standards

https://bestpractices.coreinfrastructure.org/

Properly document to_days and from_days

DateTuple::to_days() and DateTuple::from_days were both added in version 2.0.0 but not added to the CHANGELOG or README. They should be documented in both of those places.

Something's wrong in the Travis config - investigate and fix

Serialisation is confusing - months should not be zero-based when serialised

Modify MonthTuple and DateTuple to use one-based months instead of zero-based months.

This will be a major breaking change and most likely require a version bump to 2.0.0 for publishing and warnings in CHANGELOG and README.

Add function for TimeTuple to return the current time

Make readable strings customisable

Have a format more similar to the std::fmt string for getting readable strings.

For example, some users of the library may want to be able to output 2019 Jan 12 whereas others would prefer 12th January '19 or simply 12-1-19.

Implement next_date and previous_date for DateTuple

These will mimic the functionality of MonthTuple.next_month and MonthTuple.previous_month, but move a DateTuple on or back by one day.

This will lay the foundation for being able to add and subtract years, months, and days to and from DateTuples.

to_minutes methods for TimeTuple and Duration

Add functions to convert a TimeTuple or Duration into total number of minutes (ignoring seconds) similar to the existing to_seconds implementations.

Will simply be returning hours * 60 + seconds but could be a nice helper in some cases to avoid those using the library having to make the conversion.

Certify to CII Best Practices Silver Standard

https://bestpractices.coreinfrastructure.org/en/projects/3127/edit?criteria_level=1

Duration Type - Like TimeTuple but without the 24 hour limit

Move tests which can be moved into `tests` directory there

It should only be unit tests in the #[cfg(test)] block in a module. Tests which only rely on public members should be extracted out into the tests directory.

Methods to get current date don't always work

Due to differences in seconds in a year and month by month, these sometimes produce invalid values. Will be fixed as part of #26 using the new to_days and from_days helpers.

Date additions do not work as common sense expects

Bug Description
Adding dates does not conform to common sense due to the limitations of a DateTuple always being a valid date.

To Reproduce
Steps to reproduce the behavior:

1. Try to add four weeks to a date using the DateTuple Add implementation.
2. Notice that it is impossible to create a DateTuple of four weeks because { y: 0, m: 0, d: 28 } is not a valid date; there is no zeroth month.

Screenshots

Proposed Solution
Add a date duration struct similar to time_tuple::Duration so that this is possible. Implement Add<the date duration struct> for DateTuple and Sub.

In the meantime, the existing Add and Sub implementations will be removed.

DateTuple Addition/Subtraction

It would be nice to find the difference between two dates. This could include using helper methods such as to_days to facilitate this. The results should reflect exactly how many days' difference there are between.

Methods to add/subtract years/months/days from a DateTuple

See issue #2 for more of a description.

Extra attention will need to be paid such that if months are being subtracted/added, the date of month still falls within the bounds for that month.

Update README and Changelog for 1.3.0 release

DateTimeTuple doesn't implement Ord trait

Would be nice to have for ordering