refactor: use jiff for timestamp

[tisonkun]

This closes #35.

@1996fanrui if you'd like to implement something more flexible like Logback's and Log4j's PatternLayout, you can try to follow #7.

[tisonkun]

@BurntSushi FYI this is what I'm trying to replace time and humantime with jiff. The background of BurntSushi/jiff#90.

[BurntSushi]

Jiff uses API design to try to prevent you from making mistakes. For a Timestamp, the meaning of "day" is ambiguous. It might be reasonable to assume it's always 24 hours, but it might not. So Jiff forces you to make an explicit choice. You could switch to Zoned in the UTC time zone. Or you could just add 24.hours() to a Timestamp for each day if you want to make that assumption explicitly.

[tisonkun]

@BurntSushi Thanks for all your help! Final question:

Currently, I use let time = Zoned::now().strftime("%Y-%m-%dT%H:%M:%S.%6f%:z"); for both fixing the precision alignment issue and follow RFC3339 pattern.

The question is, I don't know if jiff's default pattern, i.e., 2024-08-11T22:38:58.835466+08:00[Asia/Shanghai] follows some RFC and can be parsed with other libraries (especially libraries existing outside the Rust world). Otherwise, it's a downside or even blocker I use it as a logging default timestamp format because downstream would find it challenging to parse this tribal format if it is.

[BurntSushi]

Currently, I use let time = Zoned::now().strftime("%Y-%m-%dT%H:%M:%S.%6f%:z"); for both fixing the precision alignment issue and follow RFC3339 pattern.

This is fine for fixing the precision for now until jiff::fmt::temporal::DateTimePrinter grows a precision option. But for RFC 3339, you'd want Timestamp::now().to_string().

The question is, I don't know if jiff's default pattern, i.e., 2024-08-11T22:38:58.835466+08:00[Asia/Shanghai] follows some RFC and can be parsed with other libraries (especially libraries existing outside the Rust world). Otherwise, it's a downside or even blocker I use it as a logging default timestamp format because downstream would find it challenging to parse this tribal format if it is.

Yes, as documented, it follows RFC 9557. This is documented in lots of places:

• The jiff::fmt::temporal module docs.
• The Zoned data type docs.
• In the comparison with the chrono crate.

RFC 9557 doesn't yet have broad support, but it's supported by java.time and will be supported by Temporal in ECMAScript once that lands. It will take time to propagate to other datetime libraries. But the only other way to correctly serialize a Zoned in a way that roundtrips losslessly is to encode the time zone as some out-of-band information. So if you do want the RFC 3339 format, you can either do what you're doing, or just serialize a Timestamp. The downside of the latter approach is that it always uses Z and not an offset. The former will let you encode the offset.

[tisonkun]

@BurntSushi Thanks for your detailed explaination! I'll keep the current strftime impl for now.

The downside of the latter approach is that it always uses Z and not an offset. The former will let you encode the offset.

Yes. Although humantime only accepts Z without offset, I'd prefer to deliver the offset and it's also defined part of RFC3339 - I confirm that chrono and other language's lib understand that.

Once RFC 9557 becomes more famous, I would reconsider this format. And it's always possible we add it an option in #7.

Looking forward to jiff 1.0 and I'll sooner release a logforth 0.9 for the first jiff integrated version :D

[BurntSushi]

Sweet thank you!