Re: Query: Legal TiddlyWiki Dates?

[TonyM]

TT,

I advise against this, use a new field for the dates you want to back date. I do not think this additional field is unneeded, on the contrary it is needed in my view.

Why?

Because created date is an important record of when the tiddler was first created. One day it may get you out of a pickle because you can search for all this tiddlers you created in a batch on a particular date. It also supports recently created searches and a lot more potentially.

I am happy to share the tools and methods to make use of an additional date field.

In the same vein I put a journal-date field on my journals since the title is human readable it is useful having a date serial field for date range manipulation and more. In this case I may create a log entry for a past date and when I did this it is captured in the created date. I could list all journals that were "post dated" created after the day on which they represent.

Just a view point I feel duty bound to share.

Regards

Tony

On Thursday, February 13, 2020 at 7:12:52 PM UTC+11, TiddlyTweeter wrote:

As part of creating tiddlers in "raw" format for direct insertion into TW I am manipulating the "created" date.

My question is this ...

What is the EARLIEST date you can enter?

I assume there will be a date calculation stats from in TW? (JS?)

FYI, the way I am using it is to record historical dates without having to use an additional unneeded field.

Any help appreciated!

Best wishes

TT

[Mark S.]

Since Tiddlywiki uses JavaScript, I suspect the earliest possible date is 1700-01-01.
I guess this would rule out plays by Shakespeare ...

[Eric Shulman]

On Thursday, February 13, 2020 at 12:12:52 AM UTC-8, TiddlyTweeter wrote:

As part of creating tiddlers in "raw" format for direct insertion into TW I am manipulating the "created" date.

My question is this ...

What is the EARLIEST date you can enter?

Unlike unix dates, which are stored as "seconds since start date" (which is officially 00:00:00 UTC on 1 January 1970), dates in TW are stored as a string of zeros representing year, month, day, hour, minutes, seconds, milliseconds, using zero-padded values with 4-digits for year, 3-digits for milliseconds, and 2-digits for all other values.  Thus, the earliest date that can be stored is "00000000000000000" (17 zeros in total).

If you create a tiddler with a field "testdate" containing the above string of zeros, and then display it using

<$view field="testdate" format="date" template="[UTC]YYYY 0MM 0DD 0hh:0mm:0ss.0XXX" />

The result is: 1899 11 30 00:00:00.00

I'm not sure why this is the result, but that's what it shows.

-e

 

[PMario]

On Thursday, February 13, 2020 at 4:04:43 PM UTC+1, Eric Shulman wrote:

If you create a tiddler with a field "testdate" containing the above string of zeros, and then display it using

<$view field="testdate" format="date" template="[UTC]YYYY 0MM 0DD 0hh:0mm:0ss.0XXX" />

The result is: 1899 11 30 00:00:00.00

I'm not sure why this is the result, but that's what it shows.

probably because of this: https://tc39.es/ecma262/#sec-year-number

-m

[PMario]

Hi

There seems to be an extended date in the spec: https://tc39.es/ecma262/#sec-expanded-years

Examples of date-time values with expanded years:

-271821-04-20T00:00:00Z 271822 B.C.
-000001-01-01T00:00:00Z 2 B.C.
+000000-01-01T00:00:00Z 1 B.C.
+000001-01-01T00:00:00Z 1 A.D.
+001970-01-01T00:00:00Z 1970 A.D.
+002009-12-15T00:00:00Z 2009 A.D.

+275760-09-13T00:00:00Z 275760 A.D.

BUT TW doesn't know about it. So we would need a new field prefixed: ext-date-

or something similar.

-mario

[HansWobbe]

If this is done, it could be an opportunity to also capture the value of using https://en.wikipedia.org/wiki/Julian_day.

Astronomers make extensive use of this and have even gone to the trouble of setting standards like incorporating a '0' date to help with arithmetic calculations that extend beyond https://en.wikipedia.org/wiki/Common_Era

On Saturday, February 15, 2020 at 4:45:35 AM UTC-5, PMario wrote:

Hi

There seems to be an extended date in the spec: https://tc39.es/ecma262/#sec-expanded-years

...

[Ste Wilson]

Off tiddlywiki topic.. But....How do those dates not exist? What happened?!

[Mark S.]

I know I'm probably in the minority, but I think a simple, local-time, user-readable date format would be useful. Like 1815-06-18 . With

the appropriate filters like hdays (human readable days), and macros for conversion. The TW date format is overkill for most

historical dates for which we don't have an exact time. It's also overkill for most personal entries, where the time component

can be contained in the text if necessary.

On Thursday, February 13, 2020 at 12:12:52 AM UTC-8, TiddlyTweeter wrote:

As part of creating tiddlers in "raw" format for direct insertion into TW I am manipulating the "created" date.

My question is this ...

What is the EARLIEST date you can enter?

[HansWobbe]

Ciao TT:

You are probably right that there are missing dates in the various calendar systems. 

For me, that has not been a problems since I almost never need ALL of the possible dates in a "monotonic Increasing" sequence.  Since I merely need some very precise dates in the series of all possible dates, I simply create a new (ragged) "base" that skips values I do not need and then use positional notation to encode and decode the values I want.  That approach also allows me to "level out" spikes in frequently occurring values by inserting Past and Next values in the "base" coefficients as "mid-points".  This quickly becomes a type of binary search that effectively reduces processing needs.  Finally, since symbols can be thought of as "prime numbers", the benefits of using https://en.wikipedia.org/wiki/P-adic_numbers are easily attained. 

All of this works amazing well in TiddlyWiki and significantly reduces my longing for the good old days of APL.

Admittedly, this is extremely "edge-case" case stuff so I am quite content to remain in the diminishing class of "old-timers who memorized algorithms in the good-old days"

Cheers,

Hans

On Saturday, February 15, 2020 at 8:53:28 AM UTC-5, TiddlyTweeter wrote:

Ciao Hans

...

 

I think your general point about bigger date range makes sense, but the absolute extended JS date range is still not astronomical?

Best wishes

TT

[PMario]

On Saturday, February 15, 2020 at 4:14:08 PM UTC+1, Mark S. wrote:

I know I'm probably in the minority, but I think a simple, local-time, user-readable date format would be useful. Like 1815-06-18

 

hmmm, That would be good enough, if you assume, that everyone lives in a similar time-zone as you do. But what if I live near the date-line https://en.wikipedia.org/wiki/International_Date_Line

IMO there needs to be a marker like UTC or GMT+01 or something similar. So the rest of the world knows what to do.

So ext-date-somedate 1815-06-18 (UTC)  would be OK for me personally. But that's only a date in the past of the human history.

What if I want to express the past in "homo sapiens's history" ... I thought js extended date with +-270 thousand years would be good. .... but no: See this article in The Guardian.

So we need something up to about 2 000 000 years ago. See the second chart at: https://en.wikipedia.org/wiki/Homo#Names_and_taxonomy

eg: 1.2 Mya  1.2 million years ago.

But I do want more: What's about the universe, the age of the earth or how long does our sun live?

I found Year Symbols, which should allow us to solve the problem for really big numbers ;) Especially SI prefix multipliers.

Abbreviations yr and ya may be an option too. Since they contain a shortcut for years and years ago.

So ext-date-tyranno may be 66 (mya) ... or 66 (Ma) ago.

I think it should be easy to create a parser for an extended timeline that could deal with all of those dates.

- js-extended dates are defined in the specs. years must start with + or - and have 6 digits. The rest is as known.

- SI prefixes are ka, Ma, Ga, Ta, Pa, Ea

- non-SI are kyr, myr, gyr for years and kya, mya, bya for years ago.

So if ext-date-my-date-1 would be 1.2 (bya) it should be easy to know, what I want to say.

have fun!

mario

[Mark S.]

We don't actually have exact days for events beyond about 5000 years ago. So 280000 years is fine, and 1400 times better than what we have now.

Except for that Usher guy, no one knows what day of the week the universe was created.

Presumably, you know where you live. Your local date of 1/10/2020 is good enough for you, even if you live near the date line. The date records

what date it was when you experienced the actual event. Tiddlers may need milliseconds and UTC in order to coordinate synching, but we don't need

that for most everything else in our lives. What we need is a light-weight, human readable format and kit for dealing with

dates from about 600 BC to 3000 AD.

[Mark S.]

The simple format yyyy-mm-dd is a lot more easy to read though.

The TW-based macros I wrote after some suggestions from Mat* seem to be date agnostic. I can run this:

40 days from 1860-12-1 : <<daysfrom 1860 12 1 40>>

and get this:

40 days from 1860-12-1 : 1861-1-10 **

Since I don't have my calendar from 1860/61 hanging around any more (the cat ate it),

someone else will have to verify that it's correct.

* Or someone

** Wikipedia tells me GE was written first 1860, but I suppose it was brushed up later?

On Monday, February 24, 2020 at 9:39:08 AM UTC-8, TiddlyTweeter wrote:

This thread was helpful but I want to point to a simple issue. 

I want to import Dickens' novel "Great Expectations" edition of 1867. 

At the moment I will have to create a special date field for that since TW dates start at 1899. 

That is cumbersome. IMO many users need simple creation dates prior to 1899!

TT

[TonyM]

Folks,

I have being watching this discussion with interest but also with the memory of past conversations. As can be seen the details behind dates and calendars is complex. But I would like to reiterate some points from my perspective;

• Don't mess with the current data fields tiddlers need created and modified dates and times, having such dates and times helps with detecting changes, lasts touched import batch and a lot more, reusing these dates results in a loss of information and misuse of the way in which the system makes use of them. #1
• Always use another field for extended of deep time dates
• I have also concluded and modified new journal to store the journal date in a field so I need not do date gymnastics on a user friendly title to list date ranges. 
• Just using the html input tag for date allows you to enter many different dates in a day (not time format) the day of week and validation of leap years may not work
• `<$edit-text tiddler="test" field="text" tag=input type=date/>`
  
• Even these complex dates can be converted to tiddlywiki time dates with some trivial string manipulation if relevant
• Sure perhaps we need to document of provide the tools for such extra dates but I expect there is a library that's done the work, but please keep it away from the standard tiddlywiki date format which is for within our lifetimes and more, and does a good job.
• Finally when I design a solution that involves dates it is important to be able to "assume" the modified and created date behave as designed, if you co opt them differently you may find bugs entering your date handling with the addition of macros and plugins.

#1

This is why previously I warned against using created and modified to mean something else. Like setting a false created date on a tiddler to indicate when "Telsla invented something". As soon as you use created for an occured date you no longer know when the item was created in your database (Tiddlywiki).

Providing tools for the creation and use of alternative dates and operating with their own validation logic according to a selected calendar standard is the best way to go in my view.

Regards

Tony

[TonyM]

TT,

I do which to express a different view point in the sprite of collaborative diversity.

Thanks for your concern. But I don't think it is an issue in the particular use case. E.g. excerpts of scripts written in 1957. Works fine. That dating identifies them well without need of an additional field.

 

See my most recent post why I think it is a problem 

I am happy to help with you making use of an additional field.

User created Tiddler dating would work as normal. I can't see a problem?

 

Perhaps you could not see the problem, thus I respectfully suggest their is. 

In any case, I intended the OP to be about better understanding the limits on dates in TW. I'm interested in that.

This is precisely what I am suggesting , the limits, and the limits or a de facto standard should in my view not use the system date/and time for something they are not.

Lets import some great date handling libraries and make it easy to develop and use such dates. For example the mear existence of a "historical" date in a tiddler already provides information that is for historical information which enriches the solution rather than degrade the solution.

Regards

Tony

[Mark S.]

I think Mohammad said he was going to post the date macros on his script site, but I don't see them at the moment.

Here's another home, if you're interested:

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

There have been other date manipulation macros, but these use no javascript and have a nice long date range,

though maybe only for the last 2000 years.

Because they're actually based on yyyy, mm, and dd numbers, it should be possible

to create an input for them rather easily.

I feel that the date filter operators inside of TW were made for the internal needs of TW, not

necessarily for the general user. The 1899 limitation is just one case in point. There's nothing in the core,

for instance, that would allow you to calculate all the dates in a 10 day range, or to

calculate the difference between two dates.

On Thursday, February 27, 2020 at 1:22:49 AM UTC-8, TiddlyTweeter wrote:

Ciao Tony, tx. Good to have a challenge!

It got clear its pragmatically an issue for dates prior to 1899. So I will have to add a field for older works.

I'm still not bothered for anything after that on creation date. I don't see the problem. 

Probably my laziness to never do anything a different way IF you can do it with existing tools.

Best wishes

TT

[Mohammad]

Hi Mark,

 I did not follow this thread!

By the may many thanks for giving the solution in a wiki!

I bookmarked this thread and will also doc it on TW-Scripts.

--Mohammad

[TonyM]

TT,

Answer: Because on searching for date on tiddlywiki.com It will document it? perhaps with keywords, history, historical, prehistory, ancient dates etc...

Regards

Tony

On Saturday, February 29, 2020 at 8:28:55 PM UTC+11, TiddlyTweeter wrote:

Ciao Mark & all

Mark S. wrote:

I feel that the date filter operators inside of TW were made for the internal needs of TW, not

necessarily for the general user. The 1899 limitation is just one case in point. There's nothing in the core, 

for instance, that would allow you to calculate all the dates in a 10 day range, or to

calculate the difference between two dates.

Okay. This is the likeliest explanation of why the OP arose in the first place.

So its one of those things we can address in TW (say through Mark S' good approach at https://marxsal.github.io/various/playground.html#Date%20Conversion%20Macros).

But how would a social historian get to know it existed & use it?

Thoughts

TT