Crates.io | time-fmt |
lib.rs | time-fmt |
version | 0.3.8 |
source | src |
created_at | 2022-03-05 16:17:42.956937 |
updated_at | 2022-10-17 15:10:48.642921 |
description | A strftime/strptime-like time formatter/parser for time-rs |
homepage | |
repository | https://github.com/MiSawa/time-fmt |
max_upload_size | |
id | 544103 |
size | 107,540 |
This is a library that formats/parses datetime of the time crate with somewhat more strftime
/strptime
-compatible format specification.
You should really use the format of the time crate, if there's no strong reason not to.
strftime
-like function.
%C
, %d
, %D
, %e
, %F
, %g
, %G
, %h
, %H
, %I
, %j
, %k
, %l
, %m
, %M
, %n
, %R
, %S
, %t
, %T
, %u
, %U
, %V
, %w
, %W
, %y
, %Y
, %%
.%a
, %A
, %b
, %B
, %c
, %p
, %P
, %r
, %x
, %X
.%z
, %Z
.strptime
-like function.
%C
, %d
, %D
, %e
, %F
, %h
, %H
, %I
, %j
, %k
, %l
, %m
, %M
, %n
, %R
, %S
, %t
, %T
, %W
, %y
, %Y
, %%
.%b
, %B
, %c
, %p
, %P
, %r
, %x
, %X
%z
, %Z
.%a
, %A
, %U
, %w
.strftime
-like conversion specification to Vec<FormatItem>
of the time crate.strptime
-like conversion description to Vec<FormatItem>
of the time crate.Vec<FormatItem>
instead.%E*
and %O*
should be implemented as if it were in the C/POSIX locale; i.e. fall back to the normal ones.C
, F
, G
, Y
) and flags (0
, +
).strftime
-like ones
nl_langinfo
lookups, namely %a
, %A
, %b
, %h
, %B
, %c
, %p
, %P
, %r
, %x
, and %X
are not implemented to do so. Instead, they are hardcoded to use that of C/POSIX locale.%E
are unsupported.%O
are unsupported.%z
doesn't work if you passed PrimitiveDateTime
. It'll be substituted to the empty string, as if "no time zone is determinable".%Z
works only if you used a function that takes a zone name. Otherwise substituted to the empty string, as if "no time zone is determinable".%
followed by a character that doesn't compose a conversion specifier that we support will result into an error.strptime
-like ones
%a
, %A
, %U
, and %w
are matched to the input but ignored.struct tm
of C language, inconsistent input will result in an unspecified behavior.
Result::Err
in a future release without bumping the major version.%z
, %Z
are not refleted to the returned date time. Instead, we return a pair of PrimitiveDateTime
and the parsed offset / timezone name.
Z
was given for %z
, it will be treated as same as +00:00
.strftime
-like conversion specification to Vec<FormatItem>
%C
(century) and %Z
(timezone name) are unsupported as no corresponding FormatItem
exists.strptime
-like conversion description to Vec<FormatItem>
%C
(century) and %Z
(timezone name) are unsupported as no corresponding FormatItem
exists.
%z
(timezone specifier) can't be Z
, as we can't seem to do it with FormatItem
.
Whitespaces won't eat more than one white space, as there's no repetitions in FormatItem
.
use time::{macros::{datetime, offset}, UtcOffset};
use time_fmt::{format::*, parse::*};
let dt = datetime!(2022-03-06 12:34:56);
// Format primitive date time
assert_eq!(
format_date_time("%Y-%m-%d %H:%M:%S", dt).unwrap(),
"2022-03-06 12:34:56"
);
// Format offset date time
assert_eq!(
format_offset_date_time("%Y-%m-%d %H:%M:%S %z", dt.assume_offset(offset!(+9:00))).unwrap(),
"2022-03-06 12:34:56 +0900"
);
// With timezone_name feature
assert_eq!(
format_zoned_date_time("%Y-%m-%d %H:%M:%S %Z", dt, offset!(+9:00), "JST").unwrap(),
"2022-03-06 12:34:56 JST"
);
// Parse date time
assert_eq!(
parse_date_time_maybe_with_zone("%Y-%m-%d %H:%M:%S %z", "2022-03-06 12:34:56 +0900")
.unwrap(),
(
dt,
Some(TimeZoneSpecifier::Offset(
UtcOffset::from_hms(9, 0, 0).unwrap()
))
)
);
Note for myself.
$ git switch master # make sure you're on the master branch
$ cargo release patch # to dry-run the release
$ cargo release patch --execute # to actually execute the release
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.