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

#41

“unixtime” is easy to understand for those who know, and easily searchable for the others.
Good for me! :+1:

1 Like
#42

While the conversion rules may not be what you expect, they are consistent:

  • 17-digit TWCore datetime input values (including abbreviated forms, which are automatically padded with trailing zeros) are always UTC.

  • 17-digit TWCore datetime output values (produced when no filter operand is supplied) are always UTC.

  • ISO8601/RFC2822 text inputs are assumed to be local time unless a timezone is included in the input value.

  • TWCore formatted date text output is not adjusted for timezone offset unless the “[UTC]” prefix is specified at the beginning of the filter operand.

The first two rules are necessary when working with tiddler fields containing TWCore datetime values (i.e., created and modified fields), which are always stored as UTC values. The last two rules allow for use-case specific control of timezone handling when working with user-supplied inputs and displaying user-visible outputs.

I have updated the documentation to better explain these details.
see https://tiddlytools.com/timer.html#TiddlyTools%2FTime%2FInfo
(scroll down to the section for “TiddlyTools/Time/ParseDate”)

1 Like
#43

For this case is the timezone value available as a variable to assist in this?

  • If not perhaps we should make it available in a form we can use in these operators and macros.
  • I am confident it can be obtained programmatically, it already is, but can we just ask for it or use a variable to obtain it?
#44

I did not know this!

This means that we should probably advise against using such timestamps in the way I have been using them for the last year… (Luckily, I mostly use it for dates, but all the times are off by one or two hours.)

I believe you mean that $tw.utils.formatDateString() doesn’t adjust – but in parsedate, the Date() constructor has already adjusted the input datetime to the local timezone.

So in practise, parsedate will always output time in either the computer’s local timezone, or in UTC. The original timezone information will be lost, right? Is this a problem?

Try this with a timezone other than that of your computer:

$tw.utils.formatDateString(new Date("2022-07-24 02:00 GMT-5"), "0hh:0mm:0ss TZD")

You only need to specify the timezone if it’s not your local timezone, and then you know what timezone that is, right?

Javascript – and therefore parsedate – understands the standard offset format:

{{{ [[2022-07-24 02:00 GMT-0500]parsedate[]] }}}
{{{ [[2022-07-24 02:00 UTC-0500]parsedate[]] }}}
{{{ [[2022-07-24 02:00 GMT-5]parsedate[]] }}}
{{{ [[2022-07-24 02:00 UTC-5]parsedate[]] }}}

I would advise against using timezone abbreviations, as it doesn’t seem to be complete (e.g. “CET” and “CEST” are missing), and you’re likely to get it completely wrong.

#45

Perhaps, but it seems it should be available never the less (the offset not the named abbreviations) . It may be needed to regenerate dates mistakenly stored and other potential utilities. As I read elsewhere on the internet at least we need the offset from UTC +12 -12 but I believe this may include some .5 values. If I were building a world clock perhaps I would like it.

#46

I think parsedate is excellent, but some “timezone issues” bother me.

  1. I would like to input TWCore datetimes in my local timezone
  2. I would like to output TWCore datetimes in my local timezone without having to remember the format string “YYYY0MM0DD0hh0mm0ss0XXX”
  3. I suppose someone would want to keep the specified timezone from ISO8601/RFC2822 text inputs to the output

Issue 1

This one is the most important to me, and maybe we could add a flag/suffix to the filter?

{{{ [[20220809080601]parsedate:local[]] }}}

This would only work for “17-digit TWCore datetime”, since ISO8601/RFC2822 is treated as local time by default, unless a timezone is specified.

What do you think, @EricShulman? My rationale is that I would like to manually enter dates and datetimes as “20220809” and “202208090806” in certain fields, and that they would mean the same thing as “2022-08-09” and “2022-08-09 08:06”.

(Note that Javascript parses dates without times as UTC, so I suppose “20220809” should be parsed as UTC even when the “local” suffix is used.)

Issue 2

Maybe we could add a corresponding operand?

{{{ [[20220809080601]parsedate[local]] }}}

Where “local” is shorthand for “YYYY0MM0DD0hh0mm0ss0XXX” without the UTC prefix.

Issue 3

For this, we would have to parse the timezone ourselves, as Javascript throws that information away after parsing the datetime string. The Javascript Date object only handles local time and UTC.

When formatting dates in TiddlyWiki, the “TZD” token always prints the current local timezone offset, even when you time-shift to UTC (this is possibly a bug)!

I think this may be outside the scope of parsedate.

I agree with this, sounds better than “number”.

#47

I don’t know if this fits into the thread or not, but awhile back @twMat found some algorithms, and then I did some coding that finds the date X days from a generic (not UTC) date. If you have two dates, you can calculate a day value for each with the mas-g function and then subtract them.
This can find historical (pre 1970) dates, and uses only wikitext.

https://marxsal.github.io/various/playground.html#Date%20Conversion%20Macros

1 Like