Open ebegumisa opened 9 months ago
I am working an a pull request to resolve this issue.
Hey, thanks for the comprehensive issue.
Ah, that's annoying that the fold is not handled by chrono (usually the way you resolve this with datetime types is by having a "fold" attribute which is either 0 or 1, depending on if it's the first or second 2am).
A shift_months_opt
sounds like a good start. The larger solution will probably be to emulate the way that chrono handles the addition of regular duration to a datetime around the fold. If you can get shift_months_opt
looking good I'm happy to add them and will investigate investigate improving the RelativeDuration for the 0.3 release
Thanks @olliemath,
I've sent the PR #12 adding the shift_months_opt
and related functions.
shift_months_opt
is now published under 0.2.6 - I'm going to keep this issue open to track progress on RelativeDelta - which I'll plan for 0.3.0
shift_months_opt
is now published under 0.2.6 - I'm going to keep this issue open to track progress on RelativeDelta - which I'll plan for 0.3.0
Great @olliemath . Much appreciated.
Firstly, thanks for the library.
Problem
I'm in a timezone which regrettably uses daylight saving tIme.
When taking a
chrono
DST timezone datetime and attempting to applychronoutils
shift utility functions (either directly or indirectly via a relative addition),chronoutils
panics if the computed datetime lands on a DST transition.Examples
Cause
These panics are due to the shift utils unwrapping calls to the
chrono::Datelike::with_*
functions, with the latter's doc currently stating:Proposed Solution
It would be helpful to have
*_opt
versions of the shift utils which return anOption
rather than aDatelike
, for examplepub fn shift_months_opt( .. ) -> Option<Datelike>
This way, the caller can choose how to handle DST issues. A returned
None
won't help the caller distinguish nonsensical input args from args which result in a DST transition, but callers should be able to determine that for themselves.