TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Jiff: Datetime library for Rust

448 点作者 goranmoomin10 个月前

26 条评论

sushibowl10 个月前
Overall this looks nice, but I found myself stumbling over the ToSpan syntax:<p><pre><code> let span = 5.days().hours(8).minutes(1); </code></pre> It feels sort of weird how the first number appears in front, and then all the other ones are function arguments. I suppose if you don&#x27;t like that you can just write:<p><pre><code> let span = Span::new().days(5).hours(8).minutes(1); </code></pre> at the expense of a couple characters, which is not too bad.
评论 #41031289 未加载
评论 #41031294 未加载
评论 #41035807 未加载
评论 #41031279 未加载
评论 #41050065 未加载
评论 #41031743 未加载
评论 #41032073 未加载
评论 #41037728 未加载
评论 #41031276 未加载
magnio10 个月前
I have seen many people downplaying the complexity of a datetime library. &quot;Just use UTC&#x2F;Unix time as an internal representation&quot;, &quot;just represent duration as nanoseconds&quot;, &quot;just use offset instead of timezones&quot;, and on and on<p>For anyone having that thought, try reading through the design document of Jiff (<a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;master&#x2F;DESIGN.md">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;master&#x2F;DESIGN.md</a>), which, as all things burntsushi do, is excellent and extensive. Another good read is the comparison with (mainly) chrono, the de facto standard datetime library in Rust: <a href="https:&#x2F;&#x2F;docs.rs&#x2F;jiff&#x2F;latest&#x2F;jiff&#x2F;_documentation&#x2F;comparison&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;jiff&#x2F;latest&#x2F;jiff&#x2F;_documentation&#x2F;comparison&#x2F;i...</a><p>Stuffs like DST arithmetic (that works across ser&#x2F;de!), roundable duration, timezone aware calendar arithmetic, retrospective timezone conflict detection (!), etc. all contribute to a making the library correct, capable, and pleasant to use. In my experience, chrono is a very comprehensive and &quot;correct&quot; library, but it is also rigid and not very easy to use.
评论 #41034584 未加载
评论 #41034685 未加载
评论 #41035252 未加载
评论 #41035409 未加载
评论 #41035745 未加载
评论 #41048904 未加载
评论 #41035279 未加载
评论 #41035946 未加载
mijoharas10 个月前
This looks like a cool library.<p>Does anyone know why burntsushi is making this new library? I haven&#x27;t messed around with times in rust much, but do the existing libraries have performance problems? Or are the existing API&#x27;s awkward to use? Or is he just doing it for fun, or some other reason?
评论 #41033683 未加载
评论 #41031767 未加载
评论 #41031752 未加载
tomas78910 个月前
The state of calendar libraries in Rust is less than ideal. When working with Pandas, there is .tz_convert() and .tz_localize() and that is basically it for timezone conversions. My benchmark for this is: given a date, get first hour of CET&#x2F;CEST day in UTC. In Pandas a very simple operation. In Chrono, you have to have a NaiveDate, convert to DateTime&lt;FixedOffset&gt; and then to DateTime&lt;Utc&gt;. And there is no pattern in those conversions I managed to find. Sometimes it is a member function, other times a static method on the timezone object.<p>I hope somebody will rectify this at some point. Jiff seems like a step in a right direction but the syntax is sometimes weird. I guess I’d wellcome something more predictable
评论 #41032973 未加载
hardwaresofton10 个月前
&quot;babe wake up, the new burntsushi just dropped&quot;[0]<p>On a serious note, any rustaceans in here know the reason the crate doesn&#x27;t use something like `tracing`? A bit too heavyweight maybe -- it is about half the size on crates?<p>`log` is of course fine, and I don&#x27;t know that tracing down to the calls for tz operations is a normal use case, but always interested to know if there was a specific why here.<p>[0] <a href="https:&#x2F;&#x2F;knowyourmeme.com&#x2F;memes&#x2F;wake-up-babe" rel="nofollow">https:&#x2F;&#x2F;knowyourmeme.com&#x2F;memes&#x2F;wake-up-babe</a>
评论 #41036405 未加载
sam0x1710 个月前
Not to mention that BurntSushi is the author of the entire rust regex ecosystem
评论 #41031509 未加载
demurgos10 个月前
The main issue I have with existing time libraries, in Rust or other ecosystems is poor support for leap seconds. This is mostly caused by using UNIX timestamps instead of TAI internally, and this lib is no different unfortunately. There seems to be some way to support it with tzif files, but it does not have first-class support.<p>Here is the relevant Jiff issue with more details: <a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;issues&#x2F;7">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;issues&#x2F;7</a><p>UNIX timestamps don&#x27;t use the SI second definition (instead it&#x27;s 1&#x2F;86000th of the current day, all UNIX seconds don&#x27;t have the same duration) which breaks all correct duration computations. I understand that the tradeoff was to inherit compat with older time tracking methods and enable faster calendar formatting, I disagree that it was the right trade-off. UNIX timestamps mix representation concerns with data. In my opinion, leap seconds should be treated exactly like the 29th of February or time zones.
评论 #41034996 未加载
sva_10 个月前
It&#x27;s pronounced &#x27;Giff&#x27; (with a hard &#x27;G&#x27;)
评论 #41032882 未加载
airstrike10 个月前
<i>&gt; Jiff is pronounced like &quot;gif&quot; with a soft &quot;g,&quot; as in &quot;gem.&quot;</i><p>Over my dead body!
评论 #41035173 未加载
评论 #41035763 未加载
评论 #41036125 未加载
评论 #41035340 未加载
7bit10 个月前
So, ist it pronounced jiff or gif?
评论 #41031778 未加载
评论 #41031461 未加载
评论 #41031549 未加载
评论 #41033902 未加载
alfiedotwtf10 个月前
I&#x27;ve been dealing with time and timezones for a long time, but this is the first time I have ever seen the &quot;[Olson&#x2F;Name]&quot; suffix. Is that actually standard?
评论 #41033019 未加载
评论 #41031402 未加载
returnfalse10 个月前
Looks cool, thank you burntsushi for this. I have similar complaints about existing date-time libraries in rust. I’ll replace chrono&#x2F;time with Jiff in my projects.
the__alchemist10 个月前
Comparison with Chrono link: <a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;master&#x2F;COMPARE.md#chrono-v0438">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;master&#x2F;COMPARE.md#ch...</a><p>This is interesting, in that Rust with Chrono is the best datetime experience I&#x27;ve had in any language.
arijun10 个月前
A little off topic but does anyone know the purpose of dual licensing MIT and the UNLICENSE? It seems like the second should already allow anyone to do whatever they want…
评论 #41031356 未加载
评论 #41031316 未加载
评论 #41031317 未加载
评论 #41031306 未加载
评论 #41033897 未加载
pkulak10 个月前
Thank you! Dealing with time, calendars and durations has always been the hardest part of Rust for me. And yes, I’m including the borrow checker and async!<p>It’s so painful to come from something like the JVM where time operations and formed in near natural language. From a quick glance, this looks even better than java.time.
durandal110 个月前
I really think Rust should adopt one of the popular datetime crates into the std lib - it&#x27;s not reasonable to offload researching maintainer status and quality to each developer needing to use dates correctly.
评论 #41039565 未加载
andrewfromx10 个月前
Wow! What timing. I need this. <a href="https:&#x2F;&#x2F;github.com&#x2F;andrewarrow&#x2F;toggl">https:&#x2F;&#x2F;github.com&#x2F;andrewarrow&#x2F;toggl</a> I’m doing UTC conversion in my head.
jcgrillo10 个月前
What does it mean for a Span to be negative? This is one thing I really like about Durations, they can&#x27;t be negative and therefore match physical reality.
评论 #41035527 未加载
zokier10 个月前
While this does seem to be an improvement in general, I find it extremely disappointing that we now got another, greenfield, library that ignores leap seconds and continues the propagation of UNIXy time. I appreciate that it was at least informed decision, and seems to have been tough call to make. So full respect to burntsushi nevertheless.<p>That makes it mostly uninteresting to me; nice api is nice to have, but I&#x27;d <i>personally</i> appreciate correct results more.<p>From the wider ecosystem C++ std::chrono seems like the only one that shows some promise on this front. Last I checked the implementations were not there quite yet though, and the API definitely didn&#x27;t seem all that pleasant. Maybe in couple of years we&#x27;ll see how it&#x27;ll work out.<p>Hifitime 4.0 seems like almost the only option at this point, and it is in early alpha still.<p>I recall using astropy at one point just for time calculations, but it is quite overkill solution.<p>The quest for perfect datetime lib (for any language) continues.
评论 #41033760 未加载
评论 #41034388 未加载
评论 #41034706 未加载
评论 #41033527 未加载
raasdnil10 个月前
Has to be pronounced gif right?
nsajko10 个月前
The title doesn&#x27;t conform to the HN guidelines, dang.
评论 #41033499 未加载
评论 #41031829 未加载
mrbluecoat10 个月前
bonus: it&#x27;s pronounced like &#x27;gif&#x27; ;)
mleonhard10 个月前
Thanks for making this library, BurntSushi.<p><pre><code> impl Decimal { ... &#x2F;&#x2F;&#x2F; Returns the ASCII representation of this decimal as a string slice. pub(crate) fn as_str(&amp;self) -&gt; &amp;str { &#x2F;&#x2F; SAFETY: This is safe because all bytes written to `self.buf` are &#x2F;&#x2F; guaranteed to be ASCII (including in its initial state), and thus, &#x2F;&#x2F; any subsequence is guaranteed to be valid UTF-8. unsafe { core::str::from_utf8_unchecked(self.as_bytes()) } } } </code></pre> <a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;08dfdde204c739e38147faf70b648e2d417d1c2e&#x2F;src&#x2F;fmt&#x2F;util.rs#L186">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;jiff&#x2F;blob&#x2F;08dfdde204c739e38147...</a><p>How much performance does `from_utf8_unchecked` buy us over `from_utf8`? It&#x27;s saving iterating over a 20-byte array. Because the array fits in a single cache line, the iteration will run at the CPU&#x27;s internal clock rate. I expect that a benchmark would not be able to detect the CPU time saved. Even a program that was only serializing these Decimal types at GB&#x2F;s, the difference would be barely measurable.<p>As software engineers, about 80% of our time is spent coding. And about 80% of coding time is spent learning how the thing works. If we prioritize code clarity, we speed up 64% of our future work.<p>Performance optimizations always make code less clear. Using `from_utf8_unchecked` is a performance optimization. It makes the code less clear so it needs a three-line comment.<p>Engineering is all about trade-offs. Performance optimizations can be worth their clarity cost when they bring tangible benefits. Therefore, we need to measure. The comment doesn&#x27;t say &quot;Using `from_utf8_unchecked` because it takes 1ns while `from_utf8` takes 5ns.&quot; To make sure we&#x27;re making a good tradeoff between clarity and performance, we need to measure the impact of the optimization and document it in the code.<p>Using `unsafe` also has a cost. Safety depends on invariants. Future changes to the code can break these invariants. The compiler is the most reliable method for detecting invariant-breakage. Let&#x27;s take advantage of it. This means using `unsafe` only when its use brings tangible benefits that outweigh the risks.<p>I started my professional life as a Windows sysadmin. Dealing with worms and viruses was a large and unpleasant part of my job. During university, I learned about formal verification of software. It has great potential for making our software secure. Unfortunately, the tools are very hard to use. To verify a program, one must translate it into the language of the verification tool. This is a lot of effort so few projects do it. Now with Rust, we get verification FOR FREE! It&#x27;s amazing!!!! So let&#x27;s use it and move our industry forward. Let&#x27;s make worms, viruses, ransomware, and data theft, into things from the barbaric early days.
评论 #41048942 未加载
p0w3n3d10 个月前
Name is pretentious. Jiff? Seriously? How do you read it? &quot;Gif&quot;????
noxs10 个月前
The fact that we need a such complicated datetime library just means so many unncessary artificial complexities were introduced before (yes the daylight saving, leap seconds etc.)
评论 #41031879 未加载
评论 #41032750 未加载
评论 #41035805 未加载
评论 #41032806 未加载
drtgh10 个月前
IMHO, unwrap() , expect() and company, has infected the Rust language so deeply that one wonders when (and not &quot;if&quot;) will a library send a panic and crash the whole program.<p>How could be erased those <i>panic!</i> methods that are used in most of Rust&#x27;s libraries is something that may be is beyond the possible? beside is promoted from all the Rust&#x27;s tutorials and reference code.<p>So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand.<p>I hope this philosophy do not reach the Linux kernel.
评论 #41032905 未加载
评论 #41034937 未加载
评论 #41032999 未加载
评论 #41032914 未加载
评论 #41032839 未加载