- Tons of documentation updates! (#77, #78, #80, #82 and my own
changes as well)
- `DateTime::timestamp_subsec_{millis,micros,nanos}` methods have
been added. (#81)
- 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)
- The main documentation (`src/lib.rs` AND `README.md`) now properly
link to other types when rendered.
- The role of `TimeZone` trait is explained more thoroughly.
(Hopefully) fixes#82.
- Added padding modifiers `%_?`, `%-?` and `%0?`.
- Added new specifiers `%:z` and `%.f`.
- When `%s` specifier is used with a time zone, the time zone offset was
ignored. This has been fixed.
- Several documentation fixes including the misleading presence of
colons in the `%z` specifier. `%:z` was introduced partly due to this.
Basically, this should close#12 when officially released.
- Formatting syntax is now refactored out of the rendering logic.
The main syntax is available in the `format::strftime` module,
which also serves as a documentation for the syntax.
- A parser (modelled after `strptime(3)`) has been implemented.
See the individual commits for the detailed implementation.
- There are two ways to get a timezone-aware value from a string:
`Offset` or `DateTime<FixedOffset>`. The former should be used
when the offset is known in advance (e.g. assume the local date)
while the latter should be used when the offset is unknown.
Naive types have a simple `from_str` method.
- There are some known problems with the parser (even after
tons of tests), which will be sorted out in 0.2. Known issues:
- This does not exactly handle RFC 2822 and RFC 3339, which
subtly differs from the current implementation in
case-sensitivity, whitespace handling and legacy syntax.
I'd like to integrate #24 for this cause.
- Time zone names are not recognized at all. There is even
no means to get a name itself, not sure about the resolution.
- `Parsed` does *not* constrain `year` to be non-negative,
so manually prepared `Parsed` may give a negative year.
But the current verification pass may break such cases.
- I absolutely don't know about the parser's performance!
- `AUTHORS.txt` has been added, for what it's worth.