[HN Gopher] Show HN: tu - Convert natural language date/time to UTC
___________________________________________________________________
Show HN: tu - Convert natural language date/time to UTC
Author : adius
Score : 63 points
Date : 2024-04-12 11:04 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| warrenm wrote:
| I am not 100% sure of the use case for this ... though it looks
| kinda interesting?
|
| I run my servers in UTC (as everyone should (and some (many?)
| products require)))
|
| Everything else handles timezones "correctly" (in my experience)
| TachyonicBytes wrote:
| My use-case would be exactly the one described in the README,
| for example I would like to add one-off events to my calendar
| by writing an unstructured note.
|
| For production stuff like servers I wouldn't even think about
| it.
| gmuslera wrote:
| https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/
| TachyonicBytes wrote:
| At first I thought you posted the Tuesday's printer bug
|
| https://beza1e1.tuxen.de/lore/print_on_tuesday.html
| ydant wrote:
| Not knocking the tool, just an alternative for people who might
| not be aware.
|
| GNU date almost does the same as their examples:
| date -Is -ud 'today' --> 2024-04-12T14:04:08+00:00
| date -Is -ud 'tomorrow' --> 2024-04-13T14:04:08+00:00
| date -Is -ud '2 day' --> 2024-04-14T14:04:08+00:00
| date -Is -ud '9 week' --> 2024-06-14T14:04:08+00:00
| date -Is -ud '1 month' --> 2024-05-12T14:04:08+00:00
| date -Is -ud '2024-04-10T13:31:46+04:00' -->
| 2024-04-10T09:31:46+00:00 date -Is -ud 'Wed, 14 Feb 2024
| 23:16:09 GMT' --> 2024-02-14T23:16:09+00:00
|
| And if you want Z format, you can use a custom format string:
| date -ud '1 month' +'%FT%TTZ' --> 2024-05-12T14:13:22TZ
|
| So it would be easy enough to add an alias/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't think it's quite as flexible as some libraries,
| e.g. in Python.
| smartmic wrote:
| I was thinking (and trying out) exactly the same, thanks for
| posting! There are many reasons to reinvent the wheel, so I
| have no specific feelings about this one. In my case I will
| certainly stick with GNU date. But there is one command line
| tool which complements `date` in a very helpful way:
| https://www.fresse.org/dateutils/
| derhuerst wrote:
| I built a JavaScript library for my needs:
| https://github.com/derhuerst/parse-human-relative-time
| wolverine876 wrote:
| Pretty neat, though natural language is famously ambiguous. From
| the example, tu today ->
| 2024-03-16T12:56:41.905455Z tu tomorrow ->
| 2024-03-17T12:56:41.905455Z
|
| I interpret "today" as the time period between 00:00 and
| 23:59:59.999999, and tomorrow similarly.
| NeoTar wrote:
| The classic example is 'next Saturday'. Is this _the_ next
| Saturday (since today is Friday that would be tomorrow) or the
| Saturday of _next_ week (i.e. eight days time).
|
| And then you end up with needing a locale based week, since
| different cultures (e.g. US versus UK) use different days to
| start the week (Sunday/Monday)
| dheera wrote:
| also depends if you mean "today in UTC" or "today in local time
| expressed as UTC". most people want the latter
| kelsey98765431 wrote:
| 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 "get this
| in by tomorrow" 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.
|
| Abstracting it even further into NLP is even scarier.
|
| I don'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.
| kitd wrote:
| The most complex piece of code I ever wrote was a scheduler for
| raising triggers in the a form such as "every 2 minutes, from
| midnight to 5am, on the Tues and Thurs of each week, unless it
| falls on 25th Dec", etc, etc. The main problem I recall was
| that the server running the triggers and the client entering
| them might be in different time zones, the server having to
| honour the client's version, and those TZs might have different
| DST switchover dates, etc.
|
| Basically, how humans measure time is psychopathic.
| TachyonicBytes wrote:
| I have been searching[0] for something like this, so thank you!
| It doesn't quite parse my original example, `14 december 11:20`.
| but it parses `14 december 2024 11:20`.
|
| I was not aware GNU date could do this as well, but that also
| doesn't parse my original example.
|
| 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.
|
| [0] https://emacs.stackexchange.com/questions/79703
| adius wrote:
| Thanks for the good suggestions! I added tracking issues at
| https://github.com/ad-si/tu/issues.
|
| I'd be very happy about a PR! ;-)
| axegon_ wrote:
| https://github.com/ad-si/tu/blob/main/src/main.rs#L37
|
| I'll definitely be using this but I'd suggest replacing print
| with println.
| adius wrote:
| Glad you like it! =)
|
| It's supposed to be usable "inline", so it shouldn't print a
| newline. (E.g. `touch note-$(tu yesterday).md`)
|
| Some terminals have an option to still write the $ prompt to
| the next line and use an enter symbol ([?]) to signify that no
| newline was printed.
| keybored wrote:
| I've never had a problem in Bash with `$()` and newlines. All
| tools that I've used terminate their input with a newline. Is
| this a problem in other shells, perhaps?
| arp242 wrote:
| Trailing newlines are removed in backtick and $(..)
| substitution per POSIX:
|
| > The shell shall expand the command substitution by
| executing command in a subshell environment (see Shell
| Execution Environment) and replacing the command substitution
| (the text of command plus the enclosing "$()" or backquotes)
| with the standard output of the command, removing sequences
| of one or more <newline> characters at the end of the
| substitution. Embedded <newline> characters before the end of
| the output shall not be removed; however, they may be treated
| as field delimiters and eliminated during field splitting,
| depending on the value of IFS and quoting that is in effect.
| If the output contains any null bytes, the behavior is
| unspecified.
|
| https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V.
| ..
|
| I don't know of any shell that doesn't follow that.
| bobbylarrybobby wrote:
| Can it check whether it's writing to a terminal? There are
| many programs that will write colorized output to a terminal
| but not colorized output to a file.
| ghusbands wrote:
| 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.
|
| 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/user changes their timezone), or it may become incorrect,
| as above.
| rottencupcakes wrote:
| If you're worried about the future timestamp being at a
| specific local time (say 10 AM on a future date), it's actually
| better to store a naive time and a location than the IANA
| timezone name.
|
| Then, if a state decides to stop doing DST, or any other
| funkiness like that, you can still get the time right.
| codetrotter wrote:
| What if my country splits itself in two, and the location
| "Oslo/Norway" that used to describe my time zone no longer
| describes the place I live. And they change the time zone
| offset to be one hour off from what it used to be for
| Oslo/Norway but in the place I live the time zone offset
| remains as it was before the split?
| aidenn0 wrote:
| Don't use Oslo/Norway if you're in e.g. Trondheim; store
| Trondheim/Norway.
|
| I should note that it is not possible to make a database of
| geolocation->UTC offset that is legal in all countries,
| since there are countries with disputed borders, some of
| which care _very much_ that no software imply the "wrong"
| border.
| codetrotter wrote:
| Oslo/Norway is the name that common time zone databases
| use for all of Norway.
| aidenn0 wrote:
| Comment you originally responded to suggested:
|
| > If you're worried about the future timestamp being at a
| specific local time (say 10 AM on a future date), it's
| actually better to store a naive time and a location than
| the IANA timezone name.
|
| Europe/Oslo would be the IANA name for mainland Norway
| (Svalbard and Jan Mayen are in different IANA regions).
|
| If you're meeting somewhere at a specific time, you might
| as well specify that place really precisely (Maybe:
| Nidaros Cathedral, Trondheim, Norway) and then use that
| place to infer the proper UTC offset when the date
| approaches.
|
| There's no perfect solution as landmarks, names, &c. can
| all change.
| littlestymaar wrote:
| 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...
| therein wrote:
| This is great synchronicity. I just recently needed this. And I
| needed it in a Rust project as well, can't get any better.
|
| I was trying to do stuff with chrono-english [0] and
| parse_datetime [1].
|
| I noticed chrono-english doesn't work for both `tomorrow 4pm` and
| `4pm tomorrow`.
|
| I second the desire for the timezone support.
|
| [0] https://docs.rs/chrono-english/ [1]
| https://docs.rs/parse_datetime/
| denton-scratch wrote:
| UTC is not a representation or a display-format.
|
| 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.
|
| Just quibbling about terminology! Not knocking the program, I
| like it.
| 38 wrote:
| its RFC 3339
| RadiozRadioz wrote:
| I don't think this is very well made. Uses a hand rolled parser
| with no formal grammar. Special case logic is not documented,
| e.g. https://github.com/ad-
| si/tu/blob/main/src/chrono_english/par...
|
| But I guess it solved the author's problem and we can't argue
| with that.
___________________________________________________________________
(page generated 2024-04-12 23:00 UTC)