My DATE is misbehavin'

[S. S.]

People like to keep dates in fields in different ways.

Normal people use 17-03-2019 or 17/03/2019
             Others use 03-17-2019 or 03/17/2019
Smart ones      use 2019-03-17 or 2019/03/17
The smartest   use 20190317 but it not natural to type in a date this way, and it is very difficult for the mind to "parse" & "render"

To refer to just a year, or a month of the year, or a specific day, all my dates are in 3 formats:
Today: 2019-03-17
This month: 2019-03
This year: 2019

To convert my dates auto to the default 17 character TiddlyWiki format: YYYYMMDDHHMMSSXXX
was a real pain for me. I managed to do it with a (very painful for me to have made) <<date {{!!date-field}}>> macro.

The macro takes any of the above 3 formats and AUTO converts:

2019           to 20190101000000000
2019-03      to 20190301000000000
2019-03-17 to 20190317000000000

Then comes the next problem. How do I display this?
I can't use the <$view> widget, because that can only take input from a Field, and my {{!!date-field}} is not in the right format. Only my variable holds the acceptable format.

So what's a good way to display a variable holding 20190317000000000 as: Sunday 17th March 2019

Something like: <$text text=<<date {{!!date-field}}>> format="date" template="[UTC] DDD DDth MMM YYYY"/>

Thanks.

[TonyM]

S S

Please add support to my request here https://github.com/Jermolene/TiddlyWiki5/issues/3789 on this very subject.

I try to fill the fields in the correct format in the first place, rather than convert it on the fly. I expect it may be easier in 5.1.20 because you could multiply a number by 1000000000 to get the full format. Until then consider using calc or evans formulae plugin (which also provides date manipulation) as a replaceable value. 

Be careful to use UTC in the resulting formats.

Regards

Tony

[S. S.]

Thanks Tony.

I would find your proposal perfect for my problem, and I made a comment on GitHub to that effect.

As for filling in the fields "in the correct format" - I did mention that it is not natural to fill in date fields in that way. I want to write quickly and in formats that I can READ and understand when looking at it. I compromised already by using YYYY-MM-DD instead of DD-MM-YYYY - as I can easily comprehend both of those when typing and checking for entry errors. I do not have the ability to smoothly visually check YYYYMMDD for errors - the unbroken string of numbers is too long.

By using the UTC in the $view widget template, it ensures my date does not deviate by a DAY when time zone changes affect the result. For example, when I made the first post above, my date-field held: 20190317 but the date displayed by the $view widget without [UTC] in its template attribute showed the Long Date as: Monday 18th March 2019 !!

So the question remains, - How does one easily display a Long Date held in a variable?

Regards.

[@TiddlyTweeter]

S.S. & TonyM

I have never needed to use journaling in TW. 

I will need to next month.

Are you saying its not reliable on dating?

Concerned

Josiah

[TonyM]

No Problems with Journals.

I updated the journal button to include a full "serial" date when created in a journal-date field that I use rather than trying to decode the Journal title. I then use the view widget to present it in any desirable format when I need to. Ask me if you want the code.

Use the [UTC] prefix as needed.

Regards

Tony

Regards

Tony

[TonyM]

S S,

I would store the date in the full serial number such that you can use the view widget date format when needed. You could accept a year value then append the necessary number of zeros as desired when saving into a date field. I suggest - Do not call it a date field unless it is in tiddlywiki date format. Until we can construct the date on the run with a variable being passed to the view widget this is the only way, but perhaps it is the best way anyway.

Store once, display many times in alternate formats. If you want to call a field year who cares if it contains yyyyxxxxxxxxxxxxxxxx, if you only display the year with the date format field

Also consider using a date picker macro.

Regards

On Monday, March 18, 2019 at 12:33:41 AM UTC+11, S. S. wrote:

[Mark S.]

I think this might require a JS macro. I'm thinking of a version of the "now" macro that takes a date parameter (in your own date format).

Note that padding a date the way you have will lead to a wrong displayed date unless you live very close to, or west of GMZ 0 . If you live in timezone TMZ -8, for instance, your 20190101000000 date would present a date of 12/31/2018.  A JS macro could, of course, create a date stamp offset from the date you give so the output is correct for your timezone.

A lot of people seem to think that using a JS macro is somehow inferior to using core macros and widgets, so I'm waiting to see if anyone comes up with a clever way of displaying  dates without using JS.

-- Mark

[@TiddlyTweeter]

Mark S. & others

The many discussions of dates I find confusing. I see solutions to issues I never knew existed. LIKELY because I never bothered on dates/times.

I want to avoid issues next month when I need to track through journal entries a project that needs exact recording of day and time.

Should I be concerned at default behaviour?

Yours muddled,

Josiah

[Mark S.]

Hi TT,

How are you capturing dates and times?

If you're recording the output of the <<now>> macro as a UTC stamp into a date field, then you should be good to go.

The problem comes if, like S.S., you want to roll your own date format so that you have a date that is human-readable. Then there may be complications, especially if you live away from GMT.

In your case, you live right at GMT. So you should be fine even rolling your own 20190101000000 format. Hmmm... not sure how that date will get interpreted after daylight savings time at the end of the month. Testing ... yes, looks like it takes DST into account, though I don't know how it can do that around the globe, when DST happens at different times of the year. Oh well, go to bed before 11pm and don't get up until after 1am and all should be fine ;-)

-- Mark

[@TiddlyTweeter]

Ciao Mark S.

I naively believe in the Journal button.

All I need to do is press a button that registers NOW (not <<now>>)?

All I need know is if a Journal Entry works as advertised.

I'd rather not have to deal with the square of the hypotenuse.

Josiah

[Mark S.]

No hypotenuse is good hypotenuse?

At the moment you create a tiddler, including a journal tiddler, the created field is populated with the UTC date.

Is that the field you plan to use for comparison? Or the title field? Will you want to create post-dated entries, that you may not have had time to create the first time around?

-- Mark

[@TiddlyTweeter]

Mark S.

Initially just dates and time stamps.

In Italy which is currently UTC+1.

FYI the idea is initially only to log an experiment. The timing matters.

There may be later analyses but no original times should be changed.

I'm mainly concerned its gonna get complicated if the timings are not stable.

Josiah

.

[Mark S.]

The problem with the Journal button is that it only makes one entry per day, right?

Are you using some other logging/recording macro or tool kit?

-- Mark

[@TiddlyTweeter]

Mark S. wrote:

The problem with the Journal button is that it only makes one entry per day, right?

Eek! I had no idea. That is NO good. Shouldn't a Journal Button give an exact timestamp? Otherwise why bother? I mean you don't just journal only at 00.01 am.

Are you using some other logging/recording macro or tool kit?

 No. I thought it was not needed. 

Its logging sequential events reliably that is most critical.

That is centrally important.

Josiah

[Mark S.]

Ok -- don't panic. You can make more than one tiddler a day by changing the date stamp format to include other units. Like hours, seconds, milliseconds. So maybe just workout what you want your journal titles to look like in advance.

Edit: So adding "0hh-0mm-0ss" to your journal format should assure every entry is unique (as long as you don't click faster than one a second)

-- Mark

[@TiddlyTweeter]

Very practically helpful Mark, tx.

Josiah

[S. S.]

Mark,

Don't we already have all the javascript code we need in: $:/core/modules/utils/utils.js

exports.formatDateString = function(date,template) {
etc.

I wish the <$text> widget could be extended for date formats, or perhaps the <$view> widget extended to not just display field contents, but also variable contents.

It's quite frustrating dealing with normal readable dates.

[TonyM]

S S,

Given this reoccurring issue I am taking a deep dive into dates and UTC as I did previously with the days operator. I have gained a much deeper understanding and will share the results shortly (80% completed)

The aforementioned inability to convert a variable to a date is clearly a hindrance, for which I expect to find a work around, 

However I can state that getting dates into the full serial date format, and as a UTC value (as in the created and modified fields) is the best approach because all tiddlywikis date support goes from there.

If you accept a day month or year and save them in three fields, you can then use a macro to concatenate them and generate a serial date, 

The next thing to establish is then how to save it as UTC rather than local time so when you use it it will use the local time to display it.

I have used search and prefix in the past to list dates, so I need to work out how to adjust local time to to UTC before searching.

I will share more tomorrow ie <+12 hours.

Regards

Tony

On Monday, March 18, 2019 at 12:33:41 AM UTC+11, S. S. wrote:

[Mark S.]

Just looking at the view widget code. There's a loophole that will allow you to display a utc date:

<$list filter="20190101000000000" >
<$view field="title" format="date"/>
</$list>

This works as long as there is no actual tiddler "20190101000000000" . Actually, maybe it works even if there is, but I didn't test that. You could work this into a macro where the UTC date gets passed to the filter.

Keep in mind, that your padding approach will give an incorrect output if you live west of GMT.

--Mark

On Sunday, March 17, 2019 at 6:33:41 AM UTC-7, S. S. wrote:

[S. S.]

Mark, that's AMAZING!

<$set name="date" value="201903170000000">
<$view tiddler=<<date>> field="title" format="date" template="[UTC] DDD DDth MMM YYYY"/>
<$set>

Result:  Sunday 17th March 2019

And it matters not if there is a tiddler titled: 201903170000000

Thank you so much.

Cheers.

[TonyM]

Mark and ss

Good find. So we can say to feed a value into the view template for formatting you set the tiddler to that value?

this may be a way to feed other variables into other widgets that do not accept variables.

Good hack tip.

Regards
Tony

[Mark S.]

The important bit is to set the title to the variable.

[TonyM]

Mark,

The important bit is to set the title to the variable.

Yes, as I said this opens many possibilities. As part of my comprehensive review of dates, I used this hack to produce examples of building a date from fields/variables and state tiddlers.

This should satisfy the Original post, however I am clarifying the standards to use for reliable dates. The below examples can be further generalised so one could optionally pass the contents of the wikify text field as well.

\define new-date(format:"[UTC]YYYY0MM0DD000000000")
<$wikify name="date" text="{{!!yyyy}}{{!!mm}}{{!!dd}}0000000" >
<$view tiddler=<<date>> field="title" format="date" template="$format$"/>
<$wikify>
\end
\define new-date-vars(format:"[UTC]YYYY0MM0DD000000000")
<$wikify name="date" text="<<year>><<month>><<day>>0000000" >
<$view tiddler=<<date>> field="title" format="date" template="$format$"/>
<$wikify>
\end
\define new-date-state(format:"[UTC]YYYY0MM0DD000000000")
<$wikify name="date" text="{{year}}{{month}}{{day}}0000000" >
<$view tiddler=<<date>> field="title" format="date" template="$format$"/>
<$wikify>
\end


;Constructed date
:Default serial <<new-date>>
:Selected format <<new-date format:"[UTC] DDD DDth MMM YYYY">>
;Time
:<<new-date format:"0hh:0mm">> Shows your time offset because input time is 00:00 ?
:<<new-date format:"[UTC]0hh:0mm">>  Assumes date is a UTC time


;Constructed date from variables
<$vars
year=2013
month=12
day=15
>

:Default serial <<new-date-vars>>
:Selected format <<new-date-vars format:"[UTC] DDD DDth MMM YYYY">>

</$vars>

;Constructed date from "state tiddlers"
::Default serial <<new-date-state>>
:Selected format <<new-date-state format:"[UTC] DDD DDth MMM YYYY">>

If you use the state tiddlers create a year month and day tiddler.

If someone is in a negative time zone please test, what is the time offset ?

Regards

Tony

[TonyM]

The generalised macro.

Observe my outstanding issue, 

• passing variables in the source parameter, 

and how good is the mixed version?

Regards

Tony

\define new-date(format:"[UTC]YYYY0MM0DD000000000",source:"<<year>><<month>><<day>>0000000")
<$wikify name="date" text="$source$" >

<$view tiddler=<<date>> field="title" format="date" template="$format$"/>
<$wikify>
\end

;default from variables
<$vars
year=2001
month=01
day=01

>


:Default serial <<new-date>>
:Selected format <<new-date format:"[UTC] DDD DDth MMM YYYY">>

;I do not know how to pass the source `"<<year>><<month>><<day>>0000000` yet


</$vars>


;From fields
:State <<new-date source:"{{!!yyyy}}{{!!mm}}{{!!dd}}0000000">>
:Selected format <<new-date format:"[UTC] DDD DDth MMM YYYY" source:"{{!!yyyy}}{{!!mm}}{{!!dd}}0000000">>


;From state
:State <<new-date source:"{{year}}{{month}}{{day}}0000000">>
:Selected format <<new-date format:"[UTC] DDD DDth MMM YYYY" source:"{{year}}{{month}}{{day}}0000000">>


;From mixed (Without variables)
:State <<new-date source:"2017{{!!mm}}{{day}}1200000">>
:Selected format <<new-date format:"[UTC] DDD DDth MMM YYYY" source:"2017{{!!mm}}{{day}}1200000">>

[Mark S.]

I was surprised. All the buffered dates show up correctly. I guess the "[UTC]" designation in the format fixes the offset internally.

-- Mark

[TonyM]

Mark,

What do you mean "buffered" dates"?

Here is my further research notes, illistrated with below code

Review notes

• Modified and Created are saved as UTC time, but the field transcluded adjusts it for local time, and shows the offset
• If we use the Get filter operator to obtain the created and modified dates we see the real serial number stored in the field is UTC, thus what stored it is assumed to be UTC
• If we use the View Widget to format the serial number it will adjust for local time, if we include [UTC] it will not, UTC means display the unadjusted UTC time, thus what stored it is assumed to be UTC
• If we search date time fields using the prefix operator we will get the serial number, which may (is assumed to) be UTC and thus not the local time zone
  • To do such searches you should first ensure the search date is represented as UTC or converted to UTC
  • See converting a local time to UTC time
• Thus it is clear that TiddlyWiki assumes dates to be in UTC format, now what if we are setting a time field?
  • If we are setting it to now we use the UTC version <<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">> so the UTC time is saved and the View widget returns the local time unless we ask for UTC
  • If we have different fields representing day, month year that we wish to save in a date serial number, we must first convert it to UTC before saving it.
  • See converting a local time to UTC time
• We could say the UTC describes the content of the date field. So when saving we says its UTC, when viewing we do not say UTC if we want local time

Converting a local time to UTC time

In my case my current time zone is +11, and others have for example -11

Thus to convert any date to UTC we need to change the sign and add or subtract the hours and honor the 24 hour clock

I will complete this soon but ideas appreciated

\define now-serial-date()     <<now "YYYY0MM0DD0hh0mm0ssXXX">>
\define utc-now-serial-date() <<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">>
\define this-hour-0hh()  <<now "[UTC]0hh">>
\define this-hour-here-0hh()  <<now "0hh">>
\define this-day-0dd()  <<now "[UTC]0DD">>
\define this-month-0mm() <<now "[UTC]0MM">>
\define this-year-yyyy() <<now "[UTC]YYYY">>


;Despite being easy to read the following dates will NOT be sorted correctly, accross years
:local time now: <<now "DDth mmm YYYY 0hh:0mm:0ss">>
:UTC   time now: <<now "[UTC]DDth mmm YYYY 0hh:0mm:0ss">>


:<<now-serial-date>>
:<<this-hour-0hh>>
:<<this-hour-here-0hh>>
:<<this-day-0dd>>
:<<this-month-0mm>>
:<<this-year-yyyy>>


;Use wikify to save the date value not the content of the macro
<$wikify name=now-date text=<<now-serial-date>> >
<$button set="!!saved-date" setTo=<<now-date>> >
Set to Now
</$button>
</$wikify>
<$wikify name=now-date text=<<utc-now-serial-date>> >
<$button set="!!saved-date" setTo=<<now-date>> >
Set to Now UTC
</$button>
</$wikify>




;As stored saved-date {{!!saved-date}},
:Template without UTC  <$view field=saved-date format=date template="YYYY0MM0DD0hh0mm0ssXXX"/>      OR <$view field=saved-date format=date template="DDth mmm YYYY 0hh:0mm:0ss"/> timezone applied to saved-date, so Assumes time is UTC and you want local time.
:Template With UTC     <$view field=saved-date format=date template="[UTC]YYYY0MM0DD0hh0mm0ssXXX"/> OR <$view field=saved-date format=date template="[UTC]DDth mmm YYYY 0hh:0mm:0ss"/> Does not apply timezone to saved-date  , thus treats as if the field is UTC and you want UTC
;In built dates treated specialy, translated to local time
:Serial Date <$list filter="[all[current]get[modified]]"></$list>, Modified {{!!modified}}
:Serial Date <$list filter="[all[current]get[created]]"></$list>, Created {{!!created}}

Regards

Tony

[Hubert]

Hi all,

@Mark, thanks for your clever idea with feeding variables to the view widget. This is really helpful.

I've recently built a standalone UTC converter in a single tiddler and I've attached it here if anyone finds it helpful. Simply, input your date in the text field and hit enter. The tool will translate that to UTC. Please note that this tool relies on Evan Balster's formula plugin, which you can find here. Feel free to modify the converter to your liking, of course (code-wise it may be a bit crude, but it works).

Thanks,

Hubert

[Mark S.]

I should have said "padded" dates. Creating a UTC date by padding creates a UTC representing that date at midnight, which will be <offset> number of hours different from local time.

-- Mark

On Wednesday, March 20, 2019 at 8:07:40 PM UTC-7, TonyM wrote:

Mark,

[TonyM]

Converting a time you select to UTC for storage

Using previous macro

Save date as is

<<new-date source:"{{!!yyyy}}{{!!mm}}{{!!dd}}0000000" format:"YYYY0MM0DD0hh0mm0ss0XXX">>

Convert to UTC prior to save

<<new-date source:"{{!!yyyy}}{{!!mm}}{{!!dd}}0000000" format:"[UTC]YYYY0MM0DD0hh0mm0ss0XXX">>

Note: this is useful because the default behaviour of TiddlyWiki is for the stored date and time to be UTC

Thus we should convert any time we have to UTC before saving

This is a little easier when using the now macro as adding [UTC] will add/subtract our current time zone directly.

This is our serial date format string YYYY0MM0DD0hh0mm0ss0XXX

 Tony