14 个稳定版本
使用旧的 Rust 2015
| 2.2.0 | 2021年6月19日 |
|---|---|
| 2.1.1 | 2021年3月6日 |
| 2.1.0 | 2019年11月4日 |
| 2.0.0 | 2019年4月28日 |
| 1.4.0 | 2018年11月12日 |
在 日期和时间 中排名第 90
每月下载量 68
55KB
1K SLoC
DateTime: Rust 的高层日期和时间库
Date_Time 是一个用于精度超过秒不必要的情况的高层 Rust 库。
它处理从 0000 年 1 月 1 日 00:00:00 到 9999 年 12 月 31 日 23:59:59 的可序列化的日期和时间。
注意:本 README 可能包含尚未发布的特性的文档。为确保其针对特定版本准确,请使用标签选择器并选择您使用的版本。
变更日志 - 注意 2.0.0 版本包含重大更改。
用法
在您的 Cargo.toml 中放入以下内容
[dependencies]
date_time = "2.1.1"
然后在您的 crate 根目录下放入以下内容
extern crate date_time;
概述
此库中所有类型都实现了 Debug、Copy 和 Clone 特性。
命名
该库最初是从一个具有类似功能的开源 Kotlin 库移植过来的。因此,每个类型都以 "Tuple" 后缀结尾。
从版本 1.2.1 开始,存在没有 Tuple 后缀的类型别名。
这里有一个新的 Kotlin 库替代品 在此处。
Serde 支持
此库导出的类型在 serde_support 功能标志后具有 Serialize 和 Deserialize 实现功能。
时间
TimeTuple
可以使用 timetuple::TimeTuple 类型生成时间。
时间必须使用 TimeTuple::new() 实例化,该方法接受小时、分钟和秒参数,或者使用 TimeTuple::from_seconds(),该方法只需一个总秒数。这些然后被转换成秒并再次分开以创建一个在 00:00:00 到 23:59:59 之间的元组。
TimeTuple 实现了以下特性和其他 TimeTuple 完全可比较。
PartialOrdOrdPartialEqEq
它还可以添加到另一个TimeTuple中,也可以从中减去,但用户必须注意,这将绕过午夜。
例如
TimeTuple::new(22, 0, 0) + TimeTuple::new(1, 0, 0)将产生TimeTuple { h: 23, m: 0, s:0 }TimeTuple::new(22, 0, 0) + TimeTuple::new(3, 0, 0)将产生TimeTuple { h: 1, m: 0, s:0 }
序列化
TimeTuple可以使用(由Display trait生成)to_string()和to_hhmm_string()进行序列化。
对于上午8:30:30,前者将产生"08:30:30",后者将产生"08:30"。
可以通过调用TimeTuple::from_str()并用格式为hh:mm:ss的字符串来实例化一个TimeTuple。
修改
以下方法用于操作现有的TimeTuple
add_seconds()subtract_seconds()add_minutes()subtract_minutes()add_hours()subtract_hours()
每个方法都接受一个要添加/减去的数字作为单个参数。这些方法都包装起来,以确保结果时间在00:00:00和23:59:59之间是有效的。
持续时间
对于需要存储在小时、分钟和秒中的持续时间的情况,存在第二种时间类型Duration。这与TimeTuple类型类似,但允许小时数大于24。
可以使用Duration::between()来计算任何两个DateTime之间的差异。
日期
可以使用 datetuple::DateTuple 和 monthtuple::MonthTuple 类型来生成日期。MonthTuple 类型与 DateTuple 类似,但不包括月份的日期。
DateTuple
DateTuple 将年份、月份和月份的日期封装在一个结构体中。
可以使用 DateTuple::new() 创建一个 DateTuple,传入一个介于 0 到 9999 之间的年份以及对该年份有效的月份和日期。如果年份是闰年,可以创建 2 月 29 日。
可以使用 to_days() 和 from_days() 方法将 DateTuple 转换为或从 u32 数量,该数量表示从 0000-01-01 到 DateTuple 的值(包括)的天数。
DateTuple 可以与另一个 DateTuple 完全比较,并实现了 PartialOrd、Ord、PartialEq 和 Eq。
序列化
DateTuple 可以使用 to_string()(从 Display 特性生成)和 to_readable_string() 进行序列化。
对于 2002 年 1 月 23 日,前者将生成 "2002-01-23",后者将生成 "23 Jan 2002"。
可以通过调用 DateTuple::from_str() 并传入 yyyy-mm-dd 格式的字符串来实例化 DateTuple。
如果要以可读格式列出多个 DateTuple 对象,可能需要将它们左对齐以添加一个空格,以确保对齐。这可以通过在 format!() 调用中使用格式说明符 {:>11} 来完成。
修改
以下方法用于操作现有的 DateTuple
add_days()subtract_days()add_months()subtract_months()add_years()subtract_years()
这些方法都接受一个表示要添加或减去的数字的单个参数。这些方法将始终返回一个有效日期。如果日期会落在月份的末尾,例如在闰年 2 月 29 日后添加一年,将返回该月的最后有效日期。
以下两个方法消耗一个 DateTuple 并返回另一个
next_date()previous_date()
它们的工作方式与下面描述的 next_month() 和 previous_month() 相似。
MonthTuple
MonthTuple 与 DateTuple 相同,只是没有月份的日期。
可以使用 MonthTuple::new() 来实例化,传递年份(0000-9999)和月份(1-12)。
MonthTuple 可以完全比较另一个 MonthTuple,并实现了 PartialOrd、Ord、PartialEq 和 Eq。
MonthTuple 还实现了 From<DateTuple>,因此可以使用 MonthTuple::from(date_tuple: DateTuple) 将 DateTuple 转换为 MonthTuple。
修改
以下方法用于操作现有的 MonthTuple
add_months()subtract_months()add_years()subtract_years()
每个方法都接受一个数字作为添加或减去的参数。
next_month 和 previous_month
MonthTuple 提供了两个方法:next_month 和 previous_month,它们消耗 MonthTuple 并返回按时间顺序跟随或先于它的 MonthTuple。
如果达到这些值,它们将返回 0000 年 1 月和 9999 年 12 月的最大和最小值。
这些方法消耗现有的 MonthTuple。
序列化
MonthTuple 可以使用 to_string()(从 Display 特性生成)和 to_readable_string() 进行序列化。
对于 2002 年 1 月,前者将生成 "2002-01",后者将生成 "Jan 2002"。
可以通过调用 MonthTuple::from_str() 并传入格式为 yyyy-mm 的字符串来实例化 MonthTuple。
DateTime
date_time_tuple::DateTimeTuple 类型封装了一个 DateTuple 和一个 TimeTuple。
与其他库中的其他模块一样,它与其他 DateTimeTuple 结构完全可比较。
可以使用 Duration::between() 计算两个 DateTime 之间的差异。
序列化
DateTimeTuple 可以使用 to_string()(从 Display 特性生成)和 to_readable_string() 进行序列化。
对于 2002 年 1 月 23 日上午 08:30:30,前者将生成 "2002-01-23@08:30:30",后者将生成 "23 Jan 2002 08:30:30"。
可以通过调用DateTimeTuple::from_str()来实例化一个DateTimeTuple,其中传入一个字符串,格式为yyyy-mm-dd@hh:mm:ss。
局限性
这个库是为需要高精度实现的日期而设计的,其中不需要精确度。
如果您需要一个更精确的日期包装器,请尝试使用chrono等crate。
- 这个库仅设计用于当日期只需要精确到秒级别时。
- 这个库是时区无关的;它不处理任何时区之间的差异。
- 仅支持从
01 Jan 0000 00:00:00到31 Dec 9999 23:59:59之间的日期。
漏洞
漏洞应通过GitHub问题报告(或通过电子邮件44178347+notquiteamonad@users.noreply.github.com)进行保密报告。
此仓库使用Dependabot来确保依赖项保持最新,这意味着一旦依赖项中的漏洞被修补,安全修复将尽快应用。
依赖项
~2–3.5MB
~57K SLoC