[IDEA] make it easy to convert: Fr. Apr. 23 11:10 to 202104230910 UTC as used by TW

[pmario]

Just a thought. In TW we have the date format options to creat "nice looking" date strings, but we don't have a way to do this:

Fr. Apr. 23 11:10 -> 202104230910 because TW uses UTC time internally.

IMO it would be nice to use a Journal title and convert it back to a field eg: due-date: 20210912 which then can be shown in a different format if it needed.

.... Just a thought.

[rmunn]

There are Javascript libraries to parse date strings, but TW tries not to pull in any external dependencies, so we'd have to find a library with a compatible license and copy its code into TW core. There's also the question of what date format(s) to accept: there are LOTS of date formats used around the world, and parsing them could become very complicated.

This might be better as a plugin than in TW core, now that I think about it.

[pmario]

There are Javascript libraries to parse date strings,

IMO TW already has those functions, but they are not exposed to users

[pmario]

There's also the question of what date format(s) to accept: there are LOTS of date formats used around the world, and parsing them could become very complicated.

IMO the existing JS functions already have some sophisticated parsers. see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse and: https://tc39.es/ecma262/#sec-date-time-string-format

[slaymaker1907]

Intl.DateTimeFormat seems to have pretty good support.

[rmunn]

IMO the existing JS functions already have some sophisticated parsers. see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse and: https://tc39.es/ecma262/#sec-date-time-string-format

While Date.parse does a decent job of parsing some time and date formats, I can't call it "sophisticated" by any stretch of the imagination. For example, Date.parse('Sep 12') produced different values when I tried it in Firefox vs. when I tried it in Node. In Firefox 86, it refused to parse because I hadn't given it a year, and returned NaN (not a number). In Node 14, it produced a date of midnight local time, September 12th, 2001. If you were a user expecting TiddlyWiki to parse the date "Sep 12" and assume you meant the current year, you'd be very surprised by either one of those two results.

Note also that those were the first two things I tried; I didn't try a bunch of things and cherry-pick two failures. My first two attempts at giving Date.parse the kind of input that a TW user might reasonably expect the program to handle, and Date.parse failed on both those attempts.

If we do use Date.parse, we need to be very clear in the documentation about what formats it can and can't handle. Or we could simply write a plugin that bundles something like https://github.com/wanasit/chrono into a plugin, and let a well-maintained external library (that parses dates well, not like Date.parse) do the work for us.

[pmario]

The intention for this issue was this thread: https://groups.google.com/g/tiddlywiki/c/AEvEPZaduHE/m/aPzsj9HiAAAJ

While Date.parse does a decent job of parsing some time and date formats, I can't call it "sophisticated" by any stretch of the imagination. For example, Date.parse('Sep 12') produced different values when I tried it in Firefox vs. when I tried it in Node. ...

That's a very good point. A date "value" like this is more or less useless to be used as a "value of truth". Those values have to be deterministic.

So you are right we need to have "2021 Sep. 12" or something similar. And we need to document that

eg: I do create a tiddler today and write @due-date:"Sep 12" ... This does make perfect sense for a human -- this year. ... BUT in 1+ year(s) the reader does needs additional information about "today". When was the tiddler created? This info has to come from an other context. ...

Context isn't problematic for humans. They will probably figure it out. ... BUT context is problematic for algorithms.

eg: The user starts to edit the tiddler and save it. ... So now any "automatic conversion" which is discussed at the GG. will start be be problematic. ... The mechanism, I'm interested in will need deterministic dates.

The TW core also needs to be able to handle several languages at the same time, as far as possible.

My personal tiddlers are "multi language" but I don't use the German edition, because I don't want to carry the extra weight. So I work with en-GB but I do create German formatted dates and content.

3rd party libraries most of the time carry a lot of extra weight, if we need multi language support. ... If we use 3rd party libs, we basically have to bundle them with all possible language plugins. ... I personally don't want to maintain that! - Especially for libraries, that may be gone in 18 months from now.

TW counts in decades not years. ... We have to keep that in mind.