We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timestamps::UtcOffset
I create a logger like
simple_logger::SimpleLogger::new() .with_utc_offset(time::UtcOffset::current_local_offset().unwrap()) .init() .unwrap();
at the very beginning of main() to not run into #44
main()
This logger will format all offset-ed timestamps in UTC, which makes them looks like they are in UTC but actually not.
I found the relevant change at 496d76a#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R435
Maybe we can change it to use TIMESTAMP_FORMAT_OFFSET instead?
TIMESTAMP_FORMAT_OFFSET
let instant = time::macros::datetime!(2020-03-04 05:06:07.800 +09:00); println!("{}", instant.format(&TIMESTAMP_FORMAT_UTC).unwrap()); // 2020-03-04T05:06:07.800Z println!("{}", instant.format(&TIMESTAMP_FORMAT_OFFSET).unwrap()); // 2020-03-04T05:06:07.800+09:00
In the example above, they both leaves 3 digits at fracitional part of second as requsted by #55
The text was updated successfully, but these errors were encountered:
Huh yeah, this is definitely a bug. Timestamps::UtcOffset should use TIMESTAMP_FORMAT_OFFSET not TIMESTAMP_FORMAT_UTC.
TIMESTAMP_FORMAT_UTC
I'd welcome a PR to fix this, or will get round to it once I'm next on a machine I can easily do Rust dev on. :)
Sorry, something went wrong.
Successfully merging a pull request may close this issue.
I create a logger like
at the very beginning of
main()
to not run into #44This logger will format all offset-ed timestamps in UTC, which makes them looks like they are in UTC but actually not.
I found the relevant change at 496d76a#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R435
Maybe we can change it to use
TIMESTAMP_FORMAT_OFFSET
instead?In the example above, they both leaves 3 digits at fracitional part of second as requsted by #55
The text was updated successfully, but these errors were encountered: