Closed kujeger closed 1 year ago
Merging #529 (cfb94d0) into main (02aa2b8) will decrease coverage by
0.1%
. The diff coverage is74.0%
.
@@ Coverage Diff @@
## main #529 +/- ##
=======================================
- Coverage 98.3% 98.2% -0.1%
=======================================
Files 76 77 +1
Lines 8275 8325 +50
=======================================
+ Hits 8138 8175 +37
- Misses 137 150 +13
Impacted Files | Coverage Δ | |
---|---|---|
time/src/serde/mod.rs | 96.5% <ø> (ø) |
|
time/src/serde/timestamp_millis.rs | 43.5% <43.5%> (ø) |
|
time/src/date_time.rs | 94.1% <100.0%> (+0.2%) |
:arrow_up: |
time/src/offset_date_time.rs | 100.0% <100.0%> (ø) |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Ultimately I want to add a [unix_timestamp]
component, which could have support for modifiers to determine if it's second, millisecond, microsecond, or nanosecond. As such I would prefer not to add the serde helpers here.
As to the non-serde methods, there is no reason someone cannot simply multiple the value by 1,000,000 (for milliseconds) or 1,000 (for microseconds) and then pass the value to from_unix_timestamp_nanos
. For getting the value, it can be divided by the same amount. For this reason I do not see the need to add these methods at the present time.
Hi!
First off, thanks a lot for this excellent crate.
I've been happily using
time
for a few projects, but often have the need to deserialize and parse data featuring unix timestamps in millisecond format -- usually created in some java or kotlin application where this seems to be very common.Instead of only doing local altering/parsing of this, it seems like it could be a good fit along with the existning nanosecond support.
I've tried to make the new code as close as possible to the existing nanosecond/second functions where possible.