Relative date between two given dates, not now - native tiddlywiki

#21

This is all very promising nice work team, @cdaven and “tiddlywiki timelord Eric”.

I just ask that you do not loose site of the OT and the high demand need to add and subtract time. Erics previous example makes this achievable and could be simplified with prepared macros/and variables like “oneyear” “onemonth” or ultimately an “Nth-timeunit” etc…

  • I mention this now because it would possibly not take much to go a little further and solve this long standing gap of simple date maths.
  • We must keep an eye on making this simple where possible for the range of skill levels in our community.

Love your work folks.

#22

I’ve just renamed
https://tiddlytools.com/timer.html#TiddlyTools%2FTime%2FConvertDate%2FFilter
to
https://tiddlytools.com/timer.html#TiddlyTools%2FTime%2FParseDate

and changed the filter definition to use
parsedate[...] - converts ISO8601 or TWCore datetime text to TWCore Date Formatted output
parsedate[number] - converts ISO8601 or TWCore datetime text to “unix time” signed integer value
parsedate:number[...] - converts “unix time” signed integer value to TWCore Date Formatted output

note: “:number” operator suffix and “[number]” operand value are both literal keywords

-e

1 Like
#23

I liked convertdate, but I don’t mind parsedate either. “Parse” to me is taking a string that’s not really a date and creating a date from it, while “convert” is saying that the input must be a date of some kind.

If I’m thinking out loud, maybe “number” should be “milliseconds”, and we could add “seconds” as well?:

  • parsedate[seconds]
  • parsedate[milliseconds]

Is that more understandable than “number”? At least it would give some clue as to why you’re dividing by 3600 or 3600000 and so on.

But then again, “number” is more abstract, and I think maybe using concrete terms like “seconds” or even “hours” could be confusing. I mean, a date and a time converted into “seconds”…

In C#, the DateTime class has methods AddDays(), AddHours() and AddSeconds(). If you want to subtract, you use negative numbers.

What if we could do something like this?

[{!!created}adddays[1]] for adding or subtracting days, hours, seconds. It would first convert/parse the input format, then do the arithmetic, then convert/parse back to the original format, I think.

And possibly [{!!modified}subtractdate{!!created}] to get the time difference in seconds or milliseconds?

#24

Date(), and therefore parsedate, also supports RFC 2822 datetimes, as @pmario noted here: https://github.com/Jermolene/TiddlyWiki5/pull/6512#issuecomment-1065894935

#25

For clarity, I have added links to “Javascript Date() object” and “RFC2822” in the documentation for TiddlyTools ParseDate filter:

  • Text that is recognized by the Javascript Date() object and conforms to ISO 8601 or RFC2822 date formats. Use of English day number suffixes (“st”, “nd”, “rd”, and “th”) – which are not recognized by the ISO8601 or RFC2822 standards – are also permitted, and are automatically removed before further processing.

-e

#26

I’d prefer epoch rather than number: to me, “epoch” is more searchable.

Just my 2 cents…

Fred

#27

Originally, I used “timestamp” as the keyword, but that term is also used to refer to TWCore datetime value (e.g., the format used to store the tiddler !!created and !!modified fields.)

I’m not set on “number” as the keyword… it does seem to be a bit too generic.

Previous suggestions of “milliseconds” and “seconds” are ambiguous, in that they could be interpreted as meaning “0XXX” or “SS” TW Date Format codes, respectively.

“Epoch” is a technically accurate term… but it is also a relatively unfamiliar word for some people, especially non-programmers.

I’m open to other suggestions…

-e

#28

To me an Epoch marks the beginning “new Epoc”, end or period. When one transitions from one epoch to another there are usualy major changes, so I am not even sure its a technically accurate term. eg the dinosaur epoc.

If someone can spell out this terms functionality in prose I would be happy to provide some alternatives, because I am still not sure what this hard to name term is all about.

#29

In computer datetime handling, there is the concept of counting the number of seconds since some arbitrary starting datetime. For example, many systems currently use midnight on January 1, 1970, which is sometimes referred to as the “Unix epoch” or “posix time”.

Typical usage involves converting datetime values (year/month/day/hour/minute/second) into “epoch” values, performing some simple arithmetic on those values, and then converting the result back to datetime values to store or display the results.

Using epoch values makes it much easier to add, subtract or calculate the difference between two arbitrary datetime values, since it eliminates all the complex units like minute (60 seconds), hour (60 minutes), day (24 hours), month (28, 30, or 31 days), and year (365 or 366 days).

Internally, my TiddlyTools ParseDate filter uses the Javascript Data.prototype.gettime() method to convert year/month/day/hour/minute/second values. Note that this method returns the number of milliseconds (rather than seconds) since the Unix epoch starting point of midnight on January 1 1970, which makes it better suited to working with TWCore datetime values, which are also expressed in term of milliseconds.

references:

-e

#30

Yes, Eric, I understand there this use of epoch comes from but as I understand it we are making use of the one and only Epoch - since 1 January 1970 00:00:00 UT, a point in time known as the “Unix epoch”.

  • For this reason we are not talking about different Epochs, just the Unix Epoch
  • Thus I would argue that epoch is unlikely to be a parameter because Epoch is not a variable
  • If we want to prepare for additional epochs then perhaps call it the “UnixEpoch” for which an internet search will give people the history/details. I think Unix is more well known than posix time

What if people want to store dates from antiquity -12,000AD or for that matter geological time? Do we need other Epochs?

Just trying to help

#31

Legally, “Unix” was a tradename for the specific operating system developed by AT&T, while “Posix” is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. Metaphorically, “Posix” is a classname, while “Unix” is a variablename.

see javascript - Minimum and maximum date - Stack Overflow

the precise earliest date … is Tuesday, April 20th, 271,821 BCE (BCE = Before Common Era, e.g., the year -271,821).

-e

#32

Ah, So if we want geological time we should just add a new field with a number perhaps containing only years ago from BCE, it may even just use millions of years as the unit.

  • Still my point is, if we only handle 1 epoch, ie the Posix one then no need to use epoch as a parameter.
  • Perhaps there is a word to represent 100% numerical integer dates - numerical or Integer for example.
#33

This is why the current keyword is “number”. I did consider “integer”, which might be more mathematically accurate since there is no decimal portion to the value. However, I felt that “number” is a more familiar term that is probably easier to understand by the “mathematically challenged” who might be unclear as to what an “integer” is.

#34

Yes, trying to select words for a diverse audience can be difficult, for me number is too generic perhaps that is why numeric would be better because it describes its nature eg numeric date. Number seems to be asking for a number in a date tool. It is both a number and a date.

#35

As a little personal bonus for me, the word “numeric” contains “eric” :slight_smile:

Also, one of my software-knowledgeable friends suggested “unixtime” as a keyword… primarily because searching for the phrase “unix time” will result in many good explanations.

-e

1 Like
#36

NumEric Shulman = The Rabbi Of Dates & Times, barr none at … It’s About Time

TT

#37

My thoughts: Since most keywords we’ve come up with are abstract and hard to grasp, maybe “unixtime” is the best, since that is the name of the thing itself? Anyone who knows about Unix time will understand it, but it won’t be any harder to understand for others than “numeric”.

Another thing. The macro <<now>> is quite useful when calculating time difference from a time in the past or future – but it defaults to the format “0hh:0mm, DDth MMM YYYY”, that convertdate/parsedate doesn’t understand at the moment.

I’ve come up with a few ideas:

  1. Add a regex parser to parsedate for this specific format
  2. Change the default format for <<now>>
  3. Tell people to use <now YYYY0MM0DD0hh0mm0ss0XXX> in their filters
  4. Create another macro <<isonow>> or something like that

What do you think?

#38

I am inclined to agree with this, but still want to get some more feedback before making a change from the current keyword (“number”).

Good catch!

The problem with the default format output by <<now>> (“0hh:0mm, DDth MMM YYYY”) appears to be the comma separator used between the time and date.

It seems that ISO8601 and RFC2822 only recognizes the use of comma as a decimal separator for fractional seconds which is used in some countries (e.g. “59.123” seconds is sometimes written as “59,123” seconds).

The Javascript Date() object handling does not allow the decimal comma separator at all (it returns “Invalid Date”) and truncates any fractional seconds value (e.g., “59.123” seconds is treated as just “59” seconds). Note that Javascript does recognize some additional uses of comma separators, such as “Tuesday, 02:00 July 24, 1962” (but NOT “Tuesday, 02:00, July 24, 1962”). Fortunately, these commas are extraneous non-sematic punctuation and can be safely omitted without affecting the parsing of the date or time input text.

Given the above observations, I have opted to "add a regex parser to parsedate" to automatically remove all commas from the input values, so that you can now write {{{ [<now>parsedate[]] }}} and get a valid result rather than 0NaNNaNNaNNaNNaNNaNNaN

-e

#39

In case you were wondering, Tuesday, 02:00 July 24, 1962 is the date and time of my birth. Thus, on Sunday, July 24, 2022, I will be 60 years old!

Note: just to be pendantic… since I was born in New York City (east coast USA = UTC-0500), and I now live in California (west coast USA = UTC-0800), there is a -3 hour timezone difference, so the exact astronomical anniversary of my birth at my present location would actually be at 11pm on July 23, 2022.

-e

3 Likes
#40

I have one more issue. :scream: (These issues should become unit test cases, I think.)

When not specifying timezones, it is inconsistent.

This input format will be assumed to be in UTC, but the output will be in local time:

{{{ [[202207240200]parsedate[YYYY-0MM-0DD 0hh:0mmTZD]] }}}

While this format will be assumed to be in local time, and the output as well:

{{{ [[2022-07-24 02:00:00]parsedate[YYYY-0MM-0DD 0hh:0mmTZD]] }}}

Here, both the input and output will be in UTC:

{{{ [[202207240200]parsedate[]] }}}

And finally, input is treated as local time and output in UTC:

{{{ [[2022-07-24 02:00:00]parsedate[]] }}}

My vote is for local time by default, for both input and output.