centralized date formats

[FND]

Inspired heavily by a thread on [tw]*, I think it would be a great idea
to store all date formats in a single shadow tiddler - very similar to
the way ColorPalette is used.

The primary intention is to obviate the need to modify the ViewTemplate,
which can be achieved with only a few more lines of code:
http://www.pastey.net/70045-2wwe
(still experimenal, but working)

That way I can store all my date formats in the DateFormat tiddler:
created: YYYY-0MM-0DD
modified: YYYY-0MM-0DD 0hh:0mm
timeline: ddd, YYYY-0MM-0DD
(For the timeline I use the follwoing in a systemConfig tiddler:
config.macros.timeline.dateFormat =
store.getTiddlerSlice('DateFormat','timeline');
But that could easily be adjusted in the core as well.)

I think this is a cleaner, much more user-friendly method.

Credits go to BJ, Simon and BramChen for making me aware of this method.

-- F.

* http://groups.google.com/group/TiddlyWiki/t/31c21b86a3872de4

[Udo Borkowski]

I support this proposal.

FND: if you could raise a Trac ticket for this and provide a patch file I guess there are good changes this will go into the TiddlyWiki core (Jeremy?)

Udo

----------
Udo Borkowski
http://www.abego-software.de

On 6/29/07, FND <Ace_...@gmx.net > wrote:

Inspired heavily by a thread on [tw]*, I think it would be a great idea
to store all date formats in a single shadow tiddler - very similar to
the way ColorPalette is used.

The primary intention is to obviate the need to modify the ViewTemplate,
which can be achieved with only a few more lines of code:
     http://www.pastey.net/70045-2wwe
(still experimenal, but working)

That way I can store all my date formats in the DateFormat tiddler:
     created: YYYY-0MM-0DD
     modified: YYYY-0MM-0DD 0hh:0mm
     timeline: ddd, YYYY-0MM-0DD
(For the timeline I use the follwoing in a systemConfig tiddler:
     config.macros.timeline.dateFormat =

         store.getTiddlerSlice ('DateFormat','timeline');

[Jeremy Ruston]

Yes, it's a good idea, thank you.

Would it be possible to do it just with changes to the various
templates (like PageTemplate and ViewTemplate) to reference things
like [[DateFormat::CreationDate]]?

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[BJ]

On Jul 1, 6:26 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> Yes, it's a good idea, thank you.
>
> Would it be possible to do it just with changes to the various
> templates (like PageTemplate and ViewTemplate) to reference things
> like [[DateFormat::CreationDate]]?
>

That would work for most things, but not for setting a different date
format for the timeline I believe. That took some coding in a plugin
to override the value of config.macros.timeline.dateFormat since
that's really not something used in a template tiddler (unless the
timeline macro accepts a date format).

[Jeremy Ruston]

Right, that makes sense; we'll need to upgrade the <<timeline>> macro
to give it a date format parameter.

Cheers

Jeremy

[BJ]

On Jul 2, 2:29 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> Right, that makes sense; we'll need to upgrade the <<timeline>> macro
> to give it a date format parameter.
>
> Cheers

That would be really cool... I found that changing that date format
really helped the usability of the timeline for me. I think this
technique of using the tiddler slices to be set/modify these sort of
values is going to help a lot, especially for newcomers and those who
don't have any background or interest in coding.

As for those of us who DO have that background and interest, like
myself:

I want to say how much I appreciate the tremendous work you and the
rest of the TiddlyWiki team do with all of this. I can imagine the
investment in time and mental energy (as well as money!) you've put
into this. Absolutely tremendous stuff... please never forget there
are those of us who can definitely understand and recognize the effort
put into this, and who definitely appreciate that you do.

-- BJ

[FND]

>> Would it be possible to do it just with changes to the various
>> templates (like PageTemplate and ViewTemplate) to reference things
>> like [[DateFormat::CreationDate]]?
>
> That would work for most things, but not for setting a different date
> format for the timeline I believe. That took some coding in a plugin
> to override the value of config.macros.timeline.dateFormat since
> that's really not something used in a template tiddler

Hm, now that you mention it, I don't remember why I had modified
view.handler instead of just adding the slice link to the ViewTemplate.
Maybe it was just to make the template code look prettier, but it might
also have been to allow for some sort of code reuse - though I really
couldn't tell how that should work now...

So should I submit a ticket/patch for altering the ViewTemplate and
Timeline macro then? (I haven't looked into the latter yet, but it
should not be much different from the other change - I hope... )

-- F.

[Jeremy Ruston]

> So should I submit a ticket/patch for altering the ViewTemplate and
> Timeline macro then? (I haven't looked into the latter yet, but it
> should not be much different from the other change - I hope... )

Yes, please, F, that would be terrific, many thanks,

Jeremy

>
>
> -- F.

[Jeremy Ruston]

> I want to say how much I appreciate the tremendous work you and the
> rest of the TiddlyWiki team do with all of this. I can imagine the
> investment in time and mental energy (as well as money!) you've put
> into this. Absolutely tremendous stuff... please never forget there
> are those of us who can definitely understand and recognize the effort
> put into this, and who definitely appreciate that you do.

Thanks BJ, for all of us hearing that is a tremendous payback for the
time that's been invested. I also have to immediately deflect any
praise straight back to the community here; if it wasn't for the
people who've believed and invested in TiddlyWiki I'm sure I'd have
given up on it long ago.

I've said this before, but the remarkable thing from my perspective
about open source is that you get a wonderfully clear view of what
people want; most of my life as a software designer has been spent
having to second guess what largely imaginary users might want in the
future. It's the difference between talking to someone and writing
them a letter.

Cheers

Jeremy

>
> -- BJ

[FND]

> Yes, please, F, that would be terrific, many thanks,

I think I remember why I had modified view.handler; if you use the
[[Tiddler::Slice]] technique (directly in the ViewTemplate), then the
ShortDateFormat slice must not contain spaces (or it has to be enclosed
in quotes).
But if you use getTiddlerSlice(), the respective slice is returned
correctly only if it's *not* enclosed in quotes, leading to quite a
confusing inconsistency (from the users' perspective).

So this might actually be a bug with the [[Tiddler::Slice]] processing -
though as far as I can tell, it's just getTiddlerSlice() being called in
TiddlyWiki.prototype.getTiddlerText... !?

I'll hold off on that patch until this is sorted out.

-- F.

[FND]

> I'll hold off on that patch until this is sorted out.

Here's a preview of the changed (and newly added) tiddlers:
http://www.pastey.net/70319-46ts
That might help understand the concept.
By the way: Those labels ("timestamp", "datestamp", "daystamp") are just
preliminary, but I wanted to keep it universal instead of tying each
format to a specific application or context (like "createdDate" would
do, for example).

However, I've failed to modify the timeline macro accordingly; if I
replace the originally hardcoded string
merge(config.macros.timeline,{
dateFormat: "DD MMM YYYY"});
with the function call
merge(config.macros.timeline,{
dateFormat: store.getTiddlerSlice('DateFormats','daystamp')});
I get an error "store has no properties" - so it's probably a scope
issue, but I can't really figure that out...

-- F.

[Saq Imtiaz]

The problem is that code is being run BEFORE the store has been initialized.  One solution would be to declare the date format inline in the timeline handler. Better yet, create a config.macros.timeline.init() that runs that exact code.

Cheers,
Saq

-- F.

--
TiddlyThemes.com ( http://tiddlythemes.com ) : a gallery of TiddlyWiki themes.
TiddlySnip ( http://tiddlysnip.com ) : a firefox extension that turns TiddlyWiki into a scrapbook!
LewcidTW ( http://tw.lewcid.org ) : a repository of extensions for TiddlyWiki

[FND]

Okay, here we go then:
Ticket #361
http://trac.tiddlywiki.org/ticket/361
I've created two separate patches; one for the altered ViewTemplate and
the newly-added DateFormats tiddler, the other for the changes to the
timeline macro.

[A] tiddlers
http://trac.tiddlywiki.org/attachment/ticket/361/DateFormats_tiddlers.patch

For DateFormats, I went by ISO 8601:
* timestamp: YYYY-0MM-0DD 0hh:0mm
* datestamp: YYYY-0MM-0DD
* daystamp : ddd, YYYY-0MM-0DD
This might be controversial though, so feel free to change that.
Also, I'm not sure whether slices' labels are okay like this...

[B] timeline macro
http://trac.tiddlywiki.org/attachment/ticket/361/DateFormats_timeline.patch

> One solution would be to declare the date format inline in
> the timeline handler. Better yet, create a config.macros.timeline.init()
> that runs that exact code.

Thanks for the help. I've done that now - at least I think that's what
you had in mind.

I've also removed the now-obsolete code from Lingo.js.

-- F.

[Saq Imtiaz]

On 7/8/07, FND <Ace_...@gmx.net> wrote:

Okay, here we go then:
     Ticket #361
     http://trac.tiddlywiki.org/ticket/361
I've created two separate patches; one for the altered ViewTemplate and
the newly-added DateFormats tiddler, the other for the changes to the
timeline macro.

[A] tiddlers
http://trac.tiddlywiki.org/attachment/ticket/361/DateFormats_tiddlers.patch

For DateFormats, I went by ISO 8601:
* timestamp: YYYY-0MM-0DD 0hh:0mm
* datestamp: YYYY-0MM-0DD
* daystamp : ddd, YYYY-0MM-0DD
This might be controversial though, so feel free to change that.
Also, I'm not sure whether slices' labels are okay like this...

[B] timeline macro
http://trac.tiddlywiki.org/attachment/ticket/361/DateFormats_timeline.patch

> One solution would be to declare the date format inline in
> the timeline handler. Better yet, create a config.macros.timeline.init()
> that runs that exact code.

Almost! You do not need to call the init function inside the timeline handler! All init functions for macros are automatically executed during the start up process. So currently, init is run twice! Just remove the call to init from the timeline handler.

Cheers,
Saq
 

Thanks for the help. I've done that now - at least I think that's what
you had in mind.

I've also removed the now-obsolete code from Lingo.js.


-- F.

[FND]

> Almost! You do not need to call the init function inside the timeline

> handler! [...] Just remove the call to init from the timeline handler.

Done; I've updated the attached patch - thanks!

-- F.

[Jeremy Ruston]

I've just committed a variation of your patch to update the <<timeline>> macro:

http://trac.tiddlywiki.org/changeset/2354

This version adds a third parameter to the <<timeline>> macro as follows:

<<timeline {field} {max} {dateformat}>>

where:
{field} - the tiddler field to use, usually 'modified' or 'created'
{max} - the maximum number of entries to display
{dateformat} - the date format to use

For example:

<<timeline modified 200 "ddd, YYYY-0MM-0DD">>

So, now all three of the date formats can be specified in the
PageTemplate or the ViewTemplate.

Before I take the next step and introduce the DateFormat tiddler, and
modify the default PageTemplate and ViewTemplate to reference it, I've
a couple of thoughts/questions:

- The idea of taking tiddler slices and using them for configuration
values seems awfully like the mechanism we've been talking about for
hardsetting option values in tiddlers rather than in cookies. I want
to think a bit about generalising the implemention.

- To maintain the current default behaviour, all three date formats
would actually be referencing the same tiddler slice, if we go with
your proposed naming scheme of dateformat, dayformat etc. That means
that to make it so that the format is different for the created and
modified dates, as in your example, one would still need to edit the
ViewTemplate. The alternative might be to use your earlier naming
convention where each of the three would reference a separate slice.

I'd appreciate your thoughts on these points,

Cheers

Jeremy

On 6/29/07, FND <Ace_...@gmx.net> wrote:
>

[FND]

> I've just committed a variation of your patch to update the <<timeline>> macro:

> [snip]

> This version adds a third parameter to the <<timeline>> macro

> [snip]

> So, now all three of the date formats can be specified in the
> PageTemplate or the ViewTemplate.

I hadn't even considered that - but it's probably the most reasonable
thing to do.

> The idea of taking tiddler slices and using them for configuration
> values seems awfully like the mechanism we've been talking about for
> hardsetting option values in tiddlers rather than in cookies. I want
> to think a bit about generalising the implemention.

Good point.
Generalize how though? In terms of adding functions or on a more
conceptual level (like replacing slices with a similar mechanism)?

> To maintain the current default behaviour, all three date formats
> would actually be referencing the same tiddler slice, if we go with
> your proposed naming scheme of dateformat, dayformat etc. That means
> that to make it so that the format is different for the created and
> modified dates, as in your example, one would still need to edit the
> ViewTemplate. The alternative might be to use your earlier naming
> convention where each of the three would reference a separate slice.

So instead of assigning slices by form (date format), you would assign
them by function (where they are used)?

datestamp: YYYY-0MM-0DD created : YYYY-0MM-0DD
timestamp: YYYY-0MM-0DD 0hh:0mm vs. modified: YYYY-0MM-0DD 0hh:0mm
daystamp : ddd, YYYY-0MM-0DD timeline: ddd, YYYY-0MM-0DD

That's an interestingly different perspective - and I think it's even
the better choice in this case.
My approach was (subconsciously!?) inspired by a desire for reuse (think
database normalization) - but with only three occurrences, that's hardly
an issue here.
Plus your method is probably more transparent to end users...

-- F.

[Jeremy Ruston]

What I meant about reuse was that we might be boxing ourselves into a
corner by calling the tiddler DateFormats. We might in the future want
to put other little easily customisable nuggets in there. One solution
is just to call the tiddler something more generic like SystemOptions
or LocalConfig.

Thinking about the wider question of local configuration versus
cookies, my idea is for all tiddlers tagged systemOption to be scanned
at startup, and for tiddler slices that qualify as option settings to
be stashed away in a global hashmap. Then we'd need some logic for
determining when to use a cookie versus the locally configured value.

Anyhow, the slender connection with the date format stuff could just
be that we could make that hashmap of local configuration values
available as a "virtual tiddler" that could be addressed via tiddler
slice syntax. For example, <<view modified date
[[LocalOptions::modifiedDateFormat]]>>.

I appreciate that this might all sound a bit complicated in the cold
light of print, but I quite like the way that it would unify the two
configuration mechanisms and give flexibility about how options are
recorded.

What do you think?

Cheers

Jeremy

[FND]

> What I meant about reuse was that we might be boxing ourselves into a
> corner by calling the tiddler DateFormats. We might in the future want
> to put other little easily customisable nuggets in there. One solution
> is just to call the tiddler something more generic like SystemOptions
> or LocalConfig.

Oh right, so the equivalent of the current (primitive) approach of
overriding options* with a systemConfig tiddler - that'd definitely be a
welcome change.
"LocalConfig" sounds good to me.

* http://www.tiddlywiki.org/wiki/Changing_default_options

> Then we'd need some logic for
> determining when to use a cookie versus the locally configured value.

Sounds like an easy choice to me:
cookies > LocalConfig > default settings
Though the respective author might want to disallow user customization
for certain settings - such settings might then be tagged with
"systemOptionImportant" (cf. CSS specificity):
systemOptionImportant > cookies > LocalConfig > default settings

> the slender connection with the date format stuff could just be that
> we could make that hashmap of local configuration values available as
> a "virtual tiddler" that could be addressed via tiddler slice syntax.

> [snip]

> I quite like the way that it would unify the two configuration
> mechanisms and give flexibility about how options are recorded.

I'm not sure I fully understand how this "virtual tiddler" is different
from a shadow tiddler - but the idea sounds exciting!

-- F.

[BJ]

On Jul 15, 8:59 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> I appreciate that this might all sound a bit complicated in the cold
> light of print, but I quite like the way that it would unify the two
> configuration mechanisms and give flexibility about how options are
> recorded.
>
> What do you think?

Overall, I like the approach. One possible concern about a "virtual
tiddler" is if somebody creates a "real" tiddler with the same name...
I think there would have to be some way to block that.

Regarding cookies versus values in a systemOptions tiddler, I'm sure
there are those who would like to see the use of cookies go away
anyway!! I don't know if I'd go to THAT extreme, but I think the
systemOptions approach could be used in many places where cookies are
used now... perhaps the <<option>> macro could be expanded (or a new
<<systemOption>> macro created) that would allow for those options to
be saved as a slice in some tiddler instead. This would eliminate some
of the problems in dealing with TW's in multiple places, if the
cookies don't match in all of them! The "cookies", in effect, would
be part of the TW file itself.

In the event you had both a cookie and a value in a tiddler slice for
the same thing, I think you could make an argument either way on which
one should override the other. My initial thought is cookie
overriding tiddler slice value, but I honestly couldn't tell you why!

I think a more interesting question would be an option value existed
in multiple systemOption tiddlers. If you referred to the specific
tiddler name to define the slice used in the template, it's not an
issue, but if you merge all those slices together into one virtual
tiddler you could have some issues. The simple answer is "last one
found wins", I guess, as long as there is a clear understanding of the
order in which the tiddlers are processed.

Just my 2/100 of a United States Federal Reserve Note worth...

-- BJ

[Martin Budden]

I broadly like this. But before we implement can we give some serious thought to both the name of the tiddler and the names of the slices, since once we have implemented they will be fixed. I don't really like the name LocalOptions because:

1) I don't think "local" is a term recognized by your average user

2) There is a potential for confusion with LocaleOptions, that is options pertaining to the current locale (country/language).

Also, when setting date formats there are two interacting elements: the date format preferred by the user and the date format appropriate for a given locale (translation). Currently translators have the facility to change the date format, and we need to preserve that facility (this may mean enabling it in a different form, though).

Martin

Martin

[bob]

After looking at this:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
I'd like to suggest that
yyyymmddThhmmss
be the default squashed format.

--
BB

[FND]

> I'd like to suggest that
> yyyymmddThhmmss
> be the default squashed format.

Not sure what you mean by "squashed format" here, but that format is
really not human-readable...

-- F.

[FND]

> it would be a great idea to store all date formats in a single shadow
> tiddler - very similar to the way ColorPalette is used

I have revised this concept to use regular configuration options now:
http://trac.tiddlywiki.org/ticket/361

Thoughts?

-- F.

[Nicolas Wu]

Thanks for doing that!

Just a question: I think it's right for us to adopt an ISO standard for the dates, but the standard is:
YYYY-MM-DD hh:mm
YYYY-MM-DD
and doesn't have a leading '0' before MM and DD; maybe we should stick to the standard?

Nick

[Xavier Verges]

> doesn't have a leading '0' before MM and DD; maybe we should stick to
> the standard?

I think that the leading '0' stands for 'pad with leading zeros when
shorter than the max size'.

http://tiddlywiki.com/#DateFormatString
http://tiddlywiki.org/wiki/Timestamps

may be a little missleading on this stating just "adds a leading
zero".

-Xv

On Feb 21, 10:46 am, "Nicolas Wu" <nicolas...@gmail.com> wrote:
> Thanks for doing that!
>
> Just a question: I think it's right for us to adopt an ISO standard for the
> dates, but the standard is:
> YYYY-MM-DD hh:mm
> YYYY-MM-DD
> and doesn't have a leading '0' before MM and DD; maybe we should stick to
> the standard?
>
> Nick
>

[FND]

> the [ISO 8601] standard [...] doesn't have a leading '0' before MM and DD

Actually, it does:
> Each date and time value has a fixed number of digits that must be padded
> with leading zeros.
(cf. http://en.wikipedia.org/wiki/ISO_8601)

> I think that the leading '0' stands for 'pad with leading zeros when
> shorter than the max size'.

> [the documentation] may be a little missleading on this

You're correct; I have updated the community wiki accordingly:
http://www.tiddlywiki.org/wiki/Timestamps

-- F.

[Nicolas Wu]

> I think that the leading '0' stands for 'pad with leading zeros when
> shorter than the max size'.

> [the documentation] may be a little missleading on this

Ah, that makes more sense :)