Dte: A language for expressing and calculating date and time

by nixcraft • 5 years ago

83 25 5 years ago

potiuper• 5 years ago

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.

zamadatix• 5 years ago

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.

KMnO4• 5 years ago

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.

Jaxan• 5 years ago

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.)

jfarina• 5 years ago

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

Toutouxc2• 5 years ago

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

contravariant2• 5 years ago

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.

fanf2• 5 years ago

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.

emmelaich2• 5 years ago

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)

politician• 5 years ago

Doesn't sort well.

macintux• 5 years ago

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.

bradknowles• 5 years ago

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.

jfax• 5 years ago

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.

Toutouxc2• 5 years ago

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.

pmontra• 5 years ago

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.

wruza2• 5 years ago

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.

yissp• 5 years ago

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.

solidsnack9000• 5 years ago

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).

Dte: A language for expressing and calculating date and time

Related Stories