Dte: A language for expressing and calculating date and time | Hacker News Reader

Dte: A language for expressing and calculating date and time

github.com

83 pointsnixcraft25 comments

I only have time for a quick glance, but this catched my eye instantly:

  april+1M returns 2021-05-02

Well, months are the worst beasts of all of date parts. This tool doesn’t seem to handle them if not well then at least intuitive. Adding a month to april cannot result in may 2 in a sensible way.

Some text editors have a similar feature for text lines. If you put your cursor at some column (including last one), then when moving up and down they try to retain that column if possible. E.g.

  short lin<cursor>e</cursor>
  longer line
  shrt

When you move down, a cursor selects “n” and then “t”. When you move back up, it selects “n” again and “e” again.

But if you place it at the end of line with ‘End’ key, it goes to the last char on every line when you move up/down. This is done by maintaining additional isAtEnd flag, until it is reset by a horizontal movement.

Month-to-day calculations should not add average (or now-related?) values to do a sensible thing. If you add month to a date (which for “april” I believe is “april 1”), it should just jump to “next-month 1”. If you add month to “march 31”, it should detect that it’s an end of month, and jump to “april 30” retaining isAtEnd until it’s reset by non-month operation, so +1M again gives “may 31”, and then -3M gives “feb 28(29)”. OR there should be a way to turn off “sticky end of month” mode. In no case that can result in “may 2”. Unless I’m missing something.

(I’ve made a similar library around ten years ago but never published it. It was designed for leasing contracts which love to use “a thursday before or including the fifth last day of a month next to the month in which insurance was paid” statements for their terms.

I encountered this issue in the Google Keep application, which has a periodic reminder feature. I set a reminder for August 31, repeating monthly, but this results in it skipping months with 30 days as I discovered at the end of September.

The most compact ISO-8601 format doesn’t use any separators within the date or time values, just to designate where the date field ends and where the time field begins, and that’s with an ASCII “T” character.

So long as you know what the other fields are and what their sizes are, you don’t really need separators.

Very interesting. I need to start collecting libraries that are capable of manipulating incomplete dates; twice I’ve had to implement that for work projects (Erlang and Python), but this and pdd look promising.

This seems like the kind of thing that could be implemented in Rust and then exported to (a) shared objects and (b) web assembly to be used by Python, Ruby, JS, Java, Go, &c, &c. The community would get so much more leverage out of fixes to this one library (consider the `april+1M` example) for probably the next twenty years (since it is unlikely that any of these platforms will be unamenable to all of (a) shared objects and (b) web assembly at any point in the forseeable future).

Reminds me of the Ruby library chronic https://github.com/mojombo/chronic

It's pretty good at natural language interpretation of dates, and the basic "from today" calculations, but cool to also see here natural expressions to parse between dates.

Also plain old ActiveSupport. It doesn't have the natural language goodies, but it has all kinds of handily named methods, e.g. you can write (functional folks may want to look away)

  3.weeks.ago.next_month.beginning_of_month.last_weekday.end_of_day

and it resolves to 2021-10-29 23:59:59.9999 as of today.

Functional folks could write that in Elixir as

{:ok, end_of_november} = 3 ¦> weeks ¦> ago ¦> next_month ¦> beginning_of_month ¦> last_weekday ¦> end_of_day

given the appropriate function declarations accepting at least either a number or a DateTime or some intermediate data structure as argument.

ISO(-8601) can go fly a kite. Dashes or forward slashes are confusable as subtraction and division respectively between numbers as year, month, and day separators. - and − do not have enough of a discernible difference to matter. Periods could work if not for the choice of using them to start file extensions. Commas are already used to group numbers in sets of 3 significant figures. Writing the year, month, and day as a sequence separated by commas is distinct as the month and day are at most 2 digits.

FWIW the symbol name specified is the Unicode "hypen-minus" symbol. The subtraction dash is a separate symbol.

https://www.iso.org/obp/ui#iso:std:iso:8601:-1:ed-1:v1:en

https://www.compart.com/en/unicode/U+002D

https://www.compart.com/en/unicode/U+2212

Edit: parent comment now reflects this.

But the point of the standard isn't to provide something that everyone likes perfectly it's to provide a well defined format for exchanging datetimes instead of dealing with personal or cultural formats during interchange.

Do you want to use forward slashes confusable as a multitude of other things, one of which is a path separator?

At least you can have a file named data-2021-11-13.csv.

I worked in Germany for two years and they use dots: 2021.11.13. I really like this and quickly adopted this syntax myself.

(I guess they do it the other way around though: 13.11.2021.)

Somes tools will parse it as a file extension

>13.11.2021

This is not only the German but most European way of writing date.

I don't think this is true, Italy uses generally slashes d/m/y or dashes d-m-y. France and Spain use slashes d/m/y. The Netherlands appear to use dashes: d-m-y. Hungary uses dots, but they use the y.m.d order. Sweden uses y-m-d.

You can play with this in JS :)

    const event = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
    const options = { weekday: 'long', year: 'numeric', month: 'numeric', day: 'numeric' };
    console.log(event.toLocaleDateString('de-DE', options));
    console.log(event.toLocaleDateString('it-IT', options));
    console.log(event.toLocaleDateString('fr-FR', options));
    console.log(event.toLocaleDateString('hu-HU', options));
    console.log(event.toLocaleDateString('sv-SE', options));
    console.log(event.toLocaleDateString('es-ES', options));
    console.log(event.toLocaleDateString('nl-NL', options));

My only grief with ISO8601 is that the way the timezones are denoted is somewhat unfortunate. Would have been nice if we could somehow have: 19:00+02:00 = 21:00+00:00 = 23:00-02:00, but alas.

I suppose I should also be annoyed that I somehow never manage to type dates in the correct format if I need to write them by hand, but I'm not sure if I can blame ISO for that.

The timezone sign convention is the same as the longitude sign convention: east is positive. The lat/long conventions are documented in ISO 6709, but they predate that standard, though I have not found a good history of it.

Note that these sign conventions are not universal: for example, POSIX has the reverse sign on timezone offsets because west positive was more convenient for american unix developers. There are similar oddities for longitude.

I can understand the reasoning behind it. But it's still unfortunate.

There is a more compact, less ambiguous, more universal format in my opinion: ddMMMyyyy, e.g. 28feb2021.

Yes, it's English month abbreviations but few people worldwide would not be able to take the obvious meaning.

(it's a MIL/NATO standard afaik, and has been in use for 50+ years)

(edit, timezones are single letter, e.g. Z for Zulu aka UTC)

Doesn't sort well.

Yeah. ISO8601 being alphabetically sortable is one of its most useful features.

GNU sort has support for month names.

sooooo....dollar signs? Exclamation points? What would you pick?

Is dd[poop emoji]yyyy[poop emoji]mm too informal?

Why not [heart emoji], these are dates after all.

Reply on news.ycombinator.com