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
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.
