(this uses "C" for structs and "I" for traits)
A few things to note:
- There is no such thing as
Time
, onlyNaiveTime
Date<Tz>
doesn't actually make sense.- TimeZone has an associated
Offset
type which is always aTimeZone
which implements Offset and except forLocal
is always the same type as the trait is implemented for. (That isUtc::Offset
isUtc
,FixedOffset::Offset
isFixedOffset
, butLocal::Offset
isFixedOffset
). - Almost all of the constructors for
DateTime
are onTimeZone
, although you can get to aDateTime
by way ofNaiveDateTime::...::with_timezone
, which is a really ugly API, but one that people keep re-inventing.
- Construction of DTs is confusing
- Large number of types/traits that are not necessarily named after what they
do (mostly just that constructors are in
TimeZone
) Local
is kind of just anotherFixedOffset
- Except that
FixedOffset
doesn't have a way to load the current time, justUtc.now()
andLocal.now()
. I'd rather get rid ofLocal
in favor ofFixedOffset::local_offset()
or something less ugly (chrono::now_local()
vschrono::now_utc()
?)
- Except that
- Bad error messages for parsing/unparsing
- No types for time units (
enum Month
, etcYearMonth
is obvious), this is necessary for nice iteration (current implementation in PR from gnzlbg) and maybe constructors - Obvious methods panic internally, must use
*_opt()
methods to getOptions
(not results)
definitely more
- At least think about converting to other calendar systems
- No-std support
- Iterators a PR exists, but I would like to make sure that all our iterators have an intuitive API.