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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Show HN: tu – Convert natural language date/time to UTC

83 点作者 adius大约 1 年前

13 条评论

axegon_大约 1 年前
<a href="https:&#x2F;&#x2F;github.com&#x2F;ad-si&#x2F;tu&#x2F;blob&#x2F;main&#x2F;src&#x2F;main.rs#L37">https:&#x2F;&#x2F;github.com&#x2F;ad-si&#x2F;tu&#x2F;blob&#x2F;main&#x2F;src&#x2F;main.rs#L37</a><p>I&#x27;ll definitely be using this but I&#x27;d suggest replacing print with println.
评论 #40013899 未加载
denton-scratch大约 1 年前
UTC is not a representation or a display-format.<p>That display-format appears to be (derived from?) ISO 8601. And I think ISO 8601 is not bound to UTC; it could equally be used to represent Solar Time. Possibly the most natural representation of a UTC instant would be an integer, because fundamentally UTC is a count of milliseconds.<p>Just quibbling about terminology! Not knocking the program, I like it.
评论 #40018872 未加载
评论 #40017478 未加载
TachyonicBytes大约 1 年前
I have been searching[0] for something like this, so thank you! It doesn&#x27;t quite parse my original example, `14 december 11:20`. but it parses `14 december 2024 11:20`.<p>I was not aware GNU date could do this as well, but that also doesn&#x27;t parse my original example.<p>A small configuration of adding your preferred timezone or reading the system timezone would be nice. The code seems simple enough that I may try to add it myself.<p>[0] <a href="https:&#x2F;&#x2F;emacs.stackexchange.com&#x2F;questions&#x2F;79703" rel="nofollow">https:&#x2F;&#x2F;emacs.stackexchange.com&#x2F;questions&#x2F;79703</a>
评论 #40013953 未加载
therein大约 1 年前
This is great synchronicity. I just recently needed this. And I needed it in a Rust project as well, can&#x27;t get any better.<p>I was trying to do stuff with chrono-english [0] and parse_datetime [1].<p>I noticed chrono-english doesn&#x27;t work for both `tomorrow 4pm` and `4pm tomorrow`.<p>I second the desire for the timezone support.<p>[0] <a href="https:&#x2F;&#x2F;docs.rs&#x2F;chrono-english&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;chrono-english&#x2F;</a> [1] <a href="https:&#x2F;&#x2F;docs.rs&#x2F;parse_datetime&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;parse_datetime&#x2F;</a>
wolverine876大约 1 年前
Pretty neat, though natural language is famously ambiguous. From the example,<p><pre><code> tu today -&gt; 2024-03-16T12:56:41.905455Z tu tomorrow -&gt; 2024-03-17T12:56:41.905455Z </code></pre> I interpret &quot;today&quot; as the time period between 00:00 and 23:59:59.999999, and tomorrow similarly.
评论 #40013559 未加载
评论 #40018875 未加载
评论 #40014007 未加载
littlestymaar大约 1 年前
This makes me think of a fun fact I learned this week: by default Unreal Engine parses dates with a broken regex that stops working on European daylight saving time, and pretty much everyone around here have to patch it themselves to have a game that works in summer…
warrenm大约 1 年前
I am not 100% sure of the use case for this ... though it looks kinda interesting?<p>I run my servers in UTC (as everyone should (and some (many?) products require)))<p>Everything else handles timezones &quot;correctly&quot; (in my experience)
评论 #40013479 未加载
keizo大约 1 年前
Does anyone have a good dataset for testing libraries like this? I suppose it&#x27;s not difficult to generate one these days, but curious if there is a standard.
RadiozRadioz大约 1 年前
I don&#x27;t think this is very well made. Uses a hand rolled parser with no formal grammar. Special case logic is not documented, e.g. <a href="https:&#x2F;&#x2F;github.com&#x2F;ad-si&#x2F;tu&#x2F;blob&#x2F;main&#x2F;src&#x2F;chrono_english&#x2F;parser.rs#L55">https:&#x2F;&#x2F;github.com&#x2F;ad-si&#x2F;tu&#x2F;blob&#x2F;main&#x2F;src&#x2F;chrono_english&#x2F;par...</a><p>But I guess it solved the author&#x27;s problem and we can&#x27;t argue with that.
ranger_danger大约 1 年前
how easy would this be to rewrite in C?
kelsey98765431大约 1 年前
Dates honestly terrify me. I am already in a panic state over not having some sort of alternative timekeeping system than the jumbled mess of date formats and interacting with time zones and unix time is simply unreadable, i wonder if the concept of dates should even still exist anymore. When a global org says &quot;get this in by tomorrow&quot; that could be as little as 4 hours away or 20, and i have to go do math to figure out what people even mean.<p>Abstracting it even further into NLP is even scarier.<p>I don&#x27;t have a solution I just feel deep pain about this as a remote worker dealing with logs and timestamps and who is where, there has to be some different way.
评论 #40014918 未加载
ydant大约 1 年前
Not knocking the tool, just an alternative for people who might not be aware.<p>GNU date almost does the same as their examples:<p><pre><code> date -Is -ud &#x27;today&#x27; --&gt; 2024-04-12T14:04:08+00:00 date -Is -ud &#x27;tomorrow&#x27; --&gt; 2024-04-13T14:04:08+00:00 date -Is -ud &#x27;2 day&#x27; --&gt; 2024-04-14T14:04:08+00:00 date -Is -ud &#x27;9 week&#x27; --&gt; 2024-06-14T14:04:08+00:00 date -Is -ud &#x27;1 month&#x27; --&gt; 2024-05-12T14:04:08+00:00 date -Is -ud &#x27;2024-04-10T13:31:46+04:00&#x27; --&gt; 2024-04-10T09:31:46+00:00 date -Is -ud &#x27;Wed, 14 Feb 2024 23:16:09 GMT&#x27; --&gt; 2024-02-14T23:16:09+00:00 </code></pre> And if you want Z format, you can use a custom format string:<p><pre><code> date -ud &#x27;1 month&#x27; +&#x27;%FT%TTZ&#x27; --&gt; 2024-05-12T14:13:22TZ </code></pre> So it would be easy enough to add an alias&#x2F;function to your shell configurations and just use built-in date rather than installing a new program. Assuming GNU date relative date parsing meets your needs - I don&#x27;t think it&#x27;s quite as flexible as some libraries, e.g. in Python.
评论 #40013433 未加载
评论 #40013681 未加载
评论 #40014339 未加载
评论 #40015892 未加载
ghusbands大约 1 年前
Standard PSA: Do note that storing future times only in UTC can lose important information for almost everybody at some point. When a country changes its daylight savings time dates (as happens regularly and has happened before for the US) or decides to stay in daylight savings forever (as the EU and US are both proposing), any future events stored as UTC may then be at an incorrect local time.<p>The safest format for a stored future timestamp is a local time, an IANA timezone name, and, if you need it for efficiency, a derived UTC time. But you need to rederive the UTC time whenever the timezone database changes (or whenever the related entity&#x2F;user changes their timezone), or it may become incorrect, as above.
评论 #40015556 未加载
评论 #40015893 未加载