Open sharkdp opened 7 months ago
Would probably good to take some inspiration from burntshushi's new lib https://github.com/BurntSushi/jiff
Would probably good to take some inspiration from burntshushi's new lib
Yes! I thought the same thing when I read about it. Would be interesting to port from chrono to jiff as a small experiment. jiff might be beneficial for us due to its TZ database handling strategy, which would solve https://github.com/sharkdp/numbat/issues/344 after all.
Would be interesting to port from chrono to jiff as a small experiment.
I'm doing some of these myself and adding APIs to Jiff as a result of those experiments. So if you do this, please reach out. I'd love to hear feedback. I'm keen to iterate for the next ~year and get Jiff to 1.0.
Looking at your list, I believe Jiff should support doing everything there, except for automatic locale support. For locale, I'm hoping an integration with icu
will make that work, although I haven't done any exploration there.
@BurntSushi I ported Numbat from chrono to jiff here: https://github.com/sharkdp/numbat/pull/511
I wrote some comments, which might be helpful for you to get some insights into the chrono-to-jiff journey by someone who's not yet familar with jiff.
The jiff PR has now been merged, which checks off two items from our list:
A few enhancements that I thought about while reviewing #287. Let's discuss them here and potentially implement later:
parse_datetime
should work without a UTC offset (and use the local timezone to get the offset)parse_datetime
should work for more relaxed input formats. For example, I often want to leave out seconds. I also find theT
separator between the date and the time rather unreadable (yes, I know, it's the official standard). https://crates.io/crates/chrono_parser might be usefulTZ
environment variable work (it used to, probably broken with the timezone vs offset change)==
,!=
,>
, etc. should probably work on date times@2024-02-08
or@2024-02-08@
ord"2024-02-08"
. The latter might allow us to add support for entering other things in the future. The@
syntax might be problematic, as we already use@
for decorators.Displaying of dates should potentially be configurable, or automatically adjusted using localization features. In the US, we might want to show a 12-hour based AM/PM time, in Europe, we might want to show a 24-hour based time. Chrono even has a locale feature (even though it's currently considered unstable), which would allow showing names of months/weekdays in the proper language. We do not have l10n features anywhere else in Numbat, so I'm also okay with skipping that part.now() - 1
now() -> weekday
DateTime
andTime
/second
by introducing a@lang
or@register
decorator to associate theTime
dimension and thesecond
unit with their special role.A few useful functions would be:
parse_date
(assuming 00:00:00 in the local timezone)today
, which would be the same thing asnow()
, but with a time of00:00:00
?parse_datetime
that also takes a format string?