[TWC] Editing dates for a story line

[Anton Aylward]

One of the things about writing a book/story is that you can have flashbacks, or can be telling a parallel story, unfolding in one thread the past so you can see how it influences the 'present' thread.

So on my book writing tiddlywiki I have a field for each chapter that is the 'date' -- the timeline.
In the ChapterViewTemplate

<b>Date: </b><span macro='view dateline date'></span>

But in the ChapterEditTemplate I have a problem.
Using

<b>Date: </b><span macro='edit dateline '></span>

I just get this field with a big number.
Its not a date.

Yes there are calendar popup plugins.
I've tried them and they are awkward.  I can't easily enter a date a few centuries away, past or future.
You only move one month at a time... more like that

I'd really like to be able to enter dates as the three fields, day month year, and have that converted when I press 'done' but I'm not figuring this out.  Its going to take JavaScript programming, isn't it?  I haven't found any example to cut-and-paste.  A popup/select for "month" might be asking too much.

Is there such out there?  Could someone point me in the right direction, please.
My google-fu seems to have run out.

This is "Classic". 

[Eric Shulman]

On Saturday, February 22, 2014 7:18:01 PM UTC-8, Anton Aylward wrote:

In the ChapterViewTemplate
<b>Date: </b><span macro='view dateline date'></span>
But in the ChapterEditTemplate I have a problem.

<b>Date: </b><span macro='edit dateline '></span>
I just get this field with a big number.
Its not a date.

I tried the following:

1) goto http://classic.tiddlywiki.com

2) open More>Shadowed tab

3) open EditTemplate shadow

4) edit EditTemplate

5) added: <div class='editor' macro='edit dateline'></div>

6) open ViewTemplate shadow

7) edit ViewTemplate

8) added: <div macro='view dateline date'></div>

9) create NewTiddler

10) edit NewTiddler

11) edit "1962-07-24" into dateline input field

12) press "done"

13) dateline output is displayed as: "23 July 1962"

14) edit NewTiddler again

15) dateline input field still shows "1962-07-24"

* I'm not seeing a "big number" as you reported

* The date conversion is "off by 1" ... which is a common JS problem (day and month numbers are 0-based, e.g, 0-30 for days, and 0-11 for months)

Still... this doesn't really give you what you want... which is THREE inputs in edit mode that are converted to a single datetime value for storage and display, and then split again into three values when editing.

Another possibility would be to figure out a way (via custom javascript) to force the input field to have type="date" (a new HTML5-supported input type).  This would provide a fully interactive popup calendar for selecting the desired date.  I experimented with *manually* changing the DOM element field type to "date" (by using the browser-based debugger to inspect the element and then modify the type="..." attribute by hand)... and it worked nicely.  I'll look into how to automate that, so that you can specify a date input field without a lot of hackery.

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Anton Aylward]

On 02/22/2014 10:59 PM, Eric Shulman wrote:
>
> I tried the following:
>
> [...]

> 11) edit "1962-07-24" into dateline input field

// Anton strikes forehead!

> * I'm not seeing a "big number" as you reported

> * The date conversion is "off by 1" ... Which is a common JS problem

> (day and month numbers are 0-based, e.g, 0-30 for days, and 0-11 for months)

DUH
Well, I looked at the file to see how dates were stored and they were
the bignum. So here I was trying to convert bignum to date in my head!

> Still... This doesn't really give you what you want... Which is THREE

> inputs in edit mode that are converted to a single datetime value for
> storage and display, and then split again into three values when editing.

Well that was my diea ... But now I wonder.

Moment.

Can this handle years BC and date with a year beyond 9999?

... OUCH, no.
10251-07-14 gets truncated to 1025-07-14

Maybe playing with the date format .. Or no.



--
E pluribus unum. (Out of many, one.)
- Motto for the Seal of the United States. Adopted 20 June 1782,
recommended by John Adams, Benjamin Franklin and Thomas Jefferson, 10
Aug. 1776, and proposed by Swiss artist Pierre Eugene du SimitiËre. It
had originally appeared on the title page of the Gentleman's Journal
(Jan. 1692).

[Anton Aylward]

On 02/22/2014 10:59 PM, Eric Shulman wrote:

>
>

> 11) edit "1962-07-24" into dateline input field

Not only can this not handle dates BC, it can't even handle dates early
in our era.

If I enter 63-07-14 I get a 'not-an-number' response
Presumably its doing a leading substring rather than spitting on "-".

If I enter "0063-7-14" that gets translated to "13th Jul 1963"

However if I enter "0663-07-14" that gets translated to 13th Jul 663"

So it looks like stories about the Roman Empire and such are out.




--
Quality has to be caused, not controlled.
- Philip Crosby Reflections on Quality

[Anton Aylward]

On 02/22/2014 10:59 PM, Eric Shulman wrote:

> 11) edit "1962-07-24" into dateline input field
> 12) press "done"
> 13) dateline output is displayed as: "23 July 1962"
> 14) edit NewTiddler again
> 15) dateline input field still shows "1962-07-24"

It get crazy.

I edit in the string "January 26, 2011 13:51:50" and it seems to parse
that. Presumably Date.parse() is at work.
But what gets displayed at "done" is

14th Nov 2620 22:50

However when I go back to edit more, once again there is
"January 26, 2011 13:51:50"


I also note
http://en.wikipedia.org/wiki/ISO_8601#Years


--
Processes don't do work, people do.
- John Seely Brown

[Stephan Hradek]

Sorry, Anton, but sometimes I have the slight feeling that you tend to overcomplicate things. ;)

Do you anywhere do date calculations? No? So why do you require your datefields to be "real" dates then? Why not simply use smple text fields and follow the ISO Standard and enter dates as 3 numbers, dash seperated as Year-Month-Day?

On the other hand, IF you do date calculations please come up with a good definition how you want dates before 1582 to be interpreted. Or let's say, if your story is located in Greece, how a date before 1923 is to be interpreted. And what about the Armenian calendar or the buddhist one? http://en.wikipedia.org/wiki/Gregorian_calendar

[Anton Aylward]

On 02/23/2014 01:42 AM, Stephan Hradek wrote:
> Sorry, Anton, but sometimes I have the slight feeling that you tend to
> overcomplicate things. ;)

As far as I can make out, date and date processing *is* complicated.

> Do you anywhere do date calculations? No? So why do you require your
> datefields to be "real" dates then? Why not simply use smple text fields
> and follow the ISO Standard and enter dates as 3 numbers, dash seperated
> as Year-Month-Day?

I'm not sure what you mean by "date calculations".
Firstly, within any story thread three is going to be ordering - call it
sorting - by date. The internal representation of dates seems to be a
bignum so that such comparisons can be made.

I mentioned this is for writing stories.
no doubt you've seen things in novels that red something like "three
days later". Is that what you are talking about?

> On the other hand, IF you do date calculations please come up with a
> good definition how you want dates before 1582 to be interpreted.

The issue is how they are to be interpreted, the issue is crossing that
boundary.

So long as a story line thread stays one side or the other it doesn't
matter. This is a story/novel we're talking about, not historical
research for a published doctorate! And its a 'first cut' of the
application.

What I'm concerned about is the UI, not the historic accuracy.

> Or
> let's say, if your story is located in Greece, how a date before 1923 is
> to be interpreted. And what about the Armenian calendar or the buddhist
> one? http://en.wikipedia.org/wiki/Gregorian_calendar

Now you are the one getting complicated.
Heck, what about the Vulcan and Klingon calendars, stardates and more?
http://en.wikipedia.org/wiki/Stardate - no consistency!
http://starchive.cs.umanitoba.ca/?stardates/
http://memory-beta.wikia.com/wiki/Vulcan_calendar

Heck, writing fantasy, for example, we know time doesn't pass the same
way in Fairyland as it does in the mundane world.


I don't need this. I don't need any of this. What I need is simply a
consistent and easy to use UI.

What I'm seeing and what I've posted is that this field and the parsing
with the built in Date.parse() is inconsistent. I post one date string
in the edit dialogue fields and I get something different when its
viewed. I can live with the 'off by one' error Eric mentions. That's
easy to adjust to. The inconsistency isn't.

As I said


> I edit in the string "January 26, 2011 13:51:50" [...]

> But what gets displayed at "done" is
>
> 14th Nov 2620 22:50
>
> However when I go back to edit more, once again there is
> "January 26, 2011 13:51:50"

So long as there is that kind of inconsistency this is crazy and unusable.


--
When what you are doing isn't working, you tend to do more of the same
and with greater intensity.
- Dr. Bill Maynard & Tom Champoux Heart, Soul and Spirit

[Stephan Hradek]

Am Sonntag, 23. Februar 2014 08:16:55 UTC+1 schrieb Anton Aylward:

On 02/23/2014 01:42 AM, Stephan Hradek wrote:
> Sorry, Anton, but sometimes I have the slight feeling that you tend to
> overcomplicate things. ;)

As far as I can make out, date and date processing *is* complicated.

Not at all, if you stay consistant with your strings.
 

I'm not sure what you mean by "date calculations". […]

I mentioned this is for writing stories.
no doubt you've seen things in novels that red something like "three
days later".  Is that what you are talking about?

Exactly! You will only need dates as numbers, when you want to calculate the differences between dates or want to add or substract days.

Firstly, within any story thread three is going to be ordering - call it
sorting - by date.

As I said: Stay consistant with your date formats using something like ISO8601 and you're fine with sorting.
 

 The internal representation of dates seems to be a
bignum so that such comparisons can be made.

Forget about the internal representation if you don't need calculation.
 

So long as a story line thread stays one side or the other it doesn't
matter.

You came up with the year 63 which is clearly far befor the gregorian calendar ;)
 

What I'm concerned about is the UI, not the historic accuracy.

What I'm concerned about is that you want to use something which is not appropriate for the purpose you want to use it for.

[Anton Aylward]

On 02/23/2014 03:16 AM, Stephan Hradek wrote:
> Am Sonntag, 23. Februar 2014 08:16:55 UTC+1 schrieb Anton Aylward:
>
> On 02/23/2014 01:42 AM, Stephan Hradek wrote:
> > Sorry, Anton, but sometimes I have the slight feeling that you
> tend to
> > overcomplicate things. ;)
>
> As far as I can make out, date and date processing *is* complicated.
>
> Not at all, if you stay consistant with your strings.

I said "complicated", not "complex" and having looked at the source of
the Date code and the source of a replacement which has more flexibility
and range I stick by that statement. There's a lot to do dealing with
all the possible patterns that Date.parse() has to handle but which in
fact the implementation in my browser DOES NOT HANDLE. Considering that
the implementation is 64 bits worth of milliseconds, the limit in date
range is surprising.

Looking at the code for 'moment.js', one such package, which,
incidentally, handles dates BC and dates over a much wider range

http://momentjs.com/docs/

> I'm not sure what you mean by "date calculations". […]
> I mentioned this is for writing stories.
> no doubt you've seen things in novels that red something like "three
> days later". Is that what you are talking about?
>
>
> Exactly! You will only need dates as numbers, when you want to calculate
> the differences between dates or want to add or substract days.

The classic UNIX model: milliseconds since Jan 1 1970.
But the JavaScript Date() package seems to give a lot more functions.
And somewhere along the way (a) limits the date range and (b) doesn't
implement all of the ISO standard. The background about moment.js and
an examination of the parser in that code makes this very clear.

> So long as a story line thread stays one side or the other it doesn't
> matter.
>
>
> You came up with the year 63 which is clearly far befor the gregorian
> calendar ;)

That fact is beside the point. If I'm writing about Rome in the time of
the Domitian as does Lindsey Davis
http://en.wikipedia.org/wiki/Lindsey_Davis
for example then that's possible. Or perhaps a BC date such as in the
Masters of Rome series by Colleen McCullough
http://en.wikipedia.org/wiki/Colleen_McCullough#Masters_of_Rome_series

Why shouldn't I write a story set in the first century?

Vernor Vinge has stores that have a calendar based entirely on seconds,
no months or years. Donald Kingsbury wrote
http://en.wikipedia.org/wiki/Psychohistorical_Crisis
which has a 'decimal' calendar based on the speed of light.

>
> What I'm concerned about is the UI, not the historic accuracy.
>
> What I'm concerned about is that you want to use something which is not
> appropriate for the purpose you want to use it for.

Please explain what you mean by that.
You seem to be telling me that I * have* to deal with the different
types of calendars out there, all of them, before I can write *any*
story set in *any* era. This has to be complete and perfect before I
can start.


Right now I'm thinking 'fegetaboutit' and make the "date of this scene'
a string and have a 'hidden variable' that I fill in by hand that is the
time sequence number. That way I can write Star Trek novels that mix
Earth, Vulcan and Romulan calendars with impunity. The "date" is just a
string and could even be "one month and two days later".
What I hate about that is that its a manual system not an automatic one.
Its making me do the work rather than the computer do the work and let
me get on with writing the story.

The point is the UI, the convenience of representation and the ordering
of chapters and scenes, not the academic accuracy of a calendar system.

Its the convenience that is my reason for using Tiddlywiki. Much of the
design is based on a system I had purchased but the vendor went bust and
the net-based store&licensing means I can no longer access my work.
(One reason I've come to distrust 'the cloud'.)





--
In matters of style, swim with the current;
In matters of principle, stand like a rock.
- T. Jefferson

[PMario]

On Sunday, February 23, 2014 8:16:55 AM UTC+1, Anton Aylward wrote:

What I'm seeing and what I've posted is that this field and the parsing
with the built in Date.parse() is inconsistent.  

I think, what Stephan wants to say is, you could easily use a string instead of a date.
So if you edit text you can just enter what ever you want, because it's just a string.

If you don't need date calculation eg: today + 6d -> 2014.03.01 you don't need date fields. I also think TW can't handle this calculation anyway :)

TW date format is stored in the eg: modified field like this: 201402231526 which is YYYYMMDDhhmm
So if you don't need displa format changes like convert 2014.02.23 to   Son, 23.Feb, you are good to go with a string, instead a date input.

If you sort with a date format like this: 2014.02.23 you will be fine.

even if you need

20014.02.23 a future date would be ok. if you use
02014.02.23 for today ... So the standard TW alphabetical sorting mechanism will work. If you don't want the leading zero, you'll need a plugin. (I do have one for this type of sorting. But it may not work out of the box with fields. It uses tiddler titels atm:)

BC dates may have a problem but may be test with

BC00763
BC00000
may work too if used as strings.

-mario

[Anton Aylward]

On 02/23/2014 09:32 AM, PMario wrote:
> On Sunday, February 23, 2014 8:16:55 AM UTC+1, Anton Aylward wrote:
>
> What I'm seeing and what I've posted is that this field and the parsing
> with the built in Date.parse() is inconsistent.
>
>
> I think, what Stephan wants to say is, you could easily use a string
> instead of a date.
> So if you edit text you can just enter what ever you want, because it's
> just a string.

Since I can't get the Date() in my browser to handle the range and types
of dates, it looks like I'll have to. I'm not up to programming to
over-ride that.

The downside is two-fold.
(a) I still have to have the 'hidden variable' that I maintain by hand
which determines the sequence of the chapters/scenes. Doing it by
hand is error prone and there's no guarantee that the sequence will
match the sequence semantic implicit in the string.

(b) Using Date() there is both consistency of representation and error
checking. Now I can enter nonsense like 128st Feb 2014 and it will
take it.

> If you don't need date calculation eg: today + 6d -> 2014.03.01 you
> don't need date fields. I also think TW can't handle this calculation
> anyway :)

Its not that I need to do that; I'm trying not to be too pedantic by
including comparison and ordering in 'calculation'.

> TW date format is stored in the eg: modified field like this:
> 201402231526 which is YYYYMMDDhhmm
> So if you don't need displa format changes like convert 2014.02.23 to
> Son, 23.Feb, you are good to go with a string, instead a date input.

I was under the impression that the itnrenal representation was
millseconds since an epoch date/time.

However experimenting I see what you write works. Up to a point.
And I suspect the point at which it stops woring has more to do with
Date() than Tiddlywiki.k

If I put in 001402231526 it converts that to "23rd Feb 1914 10:26"

So I'm back to the point about the restricted date ranges of the Date()
library implementation in the browser (firefox 27) I'm using.

Unless this is a TiddlyWiki feature and you can tell me how to over-ride it.

> If you sort with a date format like this: 2014.02.23 you will be fine.
>
> even if you need
>
> 20014.02.23 a future date would be ok. if you use
> 02014.02.23 for today ... So the standard TW alphabetical sorting
> mechanism will work. If you don't want the leading zero, you'll need a
> plugin. (I do have one for this type of sorting. But it may not work out
> of the box with fields. It uses tiddler titels atm:)
>
> BC dates may have a problem but may be test with
>
> BC00763
> BC00000
> may work too if used as strings.

Ah no it won't


BC0063
comes before
BC0062

And "AD" comes before "BC"
The AD numbers rise as time goes by; the BC numbers decrease as times
goes by. Its not that you can't write a sorting algorithm that is aware
of this, but the normal sorting by string isn't enough. A reverse
string sort gives:

BC0753 The founding of Rome
BC0027 The founding of the Roman Empire
BC0001 Birth of Christ?
AD2001 Destruction of the Twin Towers
AD1066 The Norman Invasion
AD0284 The ending of the Roman Empire

Correct for BC, wrong for AD
A forward string sort is correct for AD and wrong for BC.

However the +/-YYYYYY-MM-DD does work.
I think I may have to live with that.




--
To lead people, walk beside them ...
As for the best leaders, the people do not notice their existence.
The next best, the people honor and praise.
The next, the people fear;
and the next, the people hate ...
When the best leader's work is done the people say,
"We did it ourselves!"
- Lao-tsu

[Eric Shulman]

On Saturday, February 22, 2014 7:18:01 PM UTC-8, Anton Aylward wrote:

I'd really like to be able to enter dates as the three fields, day month year, and have that converted when I press 'done' but I'm not figuring this out.  Its going to take JavaScript programming, isn't it?  I haven't found any example to cut-and-paste.  A popup/select for "month" might be asking too much.

After some more thought, it occurs to me that you might avoid the entire date conversion issue entirely:

The use-case you've outlined needs to support entering, storing, displaying, and sorting by dates... but does not need to perform *calculations* on the date values themselves (e.g., given two dates, computing a 'relative date' such as "3 years, 2 months ago").

If you use separate tiddler fields to enter/store the desired day/month/year/epoch information as simple text strings, then you can use standard TWCore mechanisms, like this:

EditTemplate:

day:<span class="twochar" macro="edit day"></span>month:<span class="twochar" macro="edit month"></span>year:<span class="fourchar" macro="edit year"></span>epoch:<span class="threechar" macro="edit epoch"></span>

ViewTemplate:

Date: <span macro="view day"></span>/<span macro="view month"></span>/<span macro="view year"></span><span macro="view epoch"></span>

Note that, while there are no formal restrictions on the input format of the individual values, you will most likely want to use numeric values only, with leading zeros for single digit values (e.g., use "07" instead of "7") so that a simple *text* sort will result in proper "numeric" ordering as well.  Also note the use of CSS classnames "twochar", "threechar" and "fourchar".  These classes let you limit the length of the input fields display in the edit mode form so that they are only as big as needed (the default size is 20 or 30 characters!).  You can find these class definitions here: http://www.TiddlyTools.com/#StyleSheetShortcuts

Another issue is creating *properly* sorted lists of tiddlers as output that allows for the reverse ordering of BCE vs CE year numbers.  But it's not really all that complex... instead of writing something like:

   <<list filter [sort[dateline]]>>

and leaving it up to javascript "date magic" to do the right thing (which we know it does NOT!)... you would need to sort by more than one field and use more than one <<list>> macro, like this:

   <<list filter [epoch[BCE]][sort[-year]][sort[month]][sort[day]]>>

   <<list filter [epoch[CE]][sort[year]][sort[month]][sort[day]]>>

The first part of the filter selects only tiddlers for which the 'epoch' field has the indicated value (BCE or CE), and then sorts those tiddler according to their year/month/day. Note the leading "-" on the BCE year sort... that reverses the order of those years, just as needed!

Similarly, if you were planning to use a plugin such as ForEachTiddlerPlugin or InlineJavascriptPlugin to access the custom "dateline" field, then you would need to access the values in all the date-related fields (day,month,year,epoch) and then perhaps concatenate to produce a single text string before further processing.  But we can leave that discussion for another time.  Hopefully, the above will get you most of the way there... and you won't need anything more complicated.