[General note: if you write code or translations for SMW, it is generally b=
to write to the developers' list semediawiki-devel@.... I=
you want to be informed about internal code changes and updates, or take pa=
in design discussions, this is a good list to be on anyway. It can also be=
used by active contributors for development support questions -- but not fo=
general user support!]
Now first of all thank you very much for this nice contribution! We are awa=
of the limitations of Type:Date and would very much like to extend it=20
considerably in future versions (after 1.0, since it is a lot of work). The=
goal would then be to have one single time datatype that can handle today's=
meeting schedules as well as times around the beginning of the universe (I=
assume both of our temporal estimations of this event should be in scope ;).
More comments inline below.
On Donnerstag, 13. Dezember 2007, Temlakos wrote:
> Attached is a script I wrote for defining a new data type for Semantic
> MediaWiki. I call it the "Historical date."
> The Date datatype (available in SMW 1.0 RC1/2) uses a signed 32-bit
> integer to store the number of seconds before or since the Unix Epoch
> (midnight on New Year's Eve 1969-70). That limits its usefulness to most
> of the twentieth century and barely more than a third of the
> twenty-first. In 2038, we are /going/ to have another dating crisis when
> the Unix Era tops out.
Yes. The new Type:Date is scheduled to appear strictly before that.
> I am an administrator and developer on CreationWiki:
> Our site is an encyclopedia. And one of the topics we treat is ancient
> history. /Very/ ancient history. And certainly history going back
> further than the twentieth century according to the Gregorian calendar.
> To that end, I reinvented the date type, with these premises:
> Instead of a 32-bit signed integer, I use a 64-bit signed /float/.
> Instead of "number of seconds before or since the UNIX Epoch", I store
> the number of /days/, and the fraction of a day, since noon (UTC)
> Monday, January 1, 4713 BC (Julian calendar). This is the /Julian Day/
> best known to astronomers.
> Instead of a preconfigured UNIX-string parser, I wrote my own parser,
> using regular expressions to screen and parse either an ISO-8601-style
> date string or the usual kind of date that an editor might write.
> I declared a number of static private arrays, each containing the names
> of the calendar months in various languages. These happen to be the
> languages into which our site has expanded, but of course I know of no
> reason why this data type oughtn't to support names given in Russian or
> Slovak or any other language into which you might wish to translate SMW
> as a whole.
> To convert dates back and forth between Julian days and the usual year,
> month, and day values, I borrowed some algorithms from John Walker at
> <http://www.fourmilab.ch>. He has explicitly declared that all his
> scripts and algorithms are in the public domain.
> You will find that the attached PHP script is completely self-contained;
> all you need is to make a "hook" in SMW_DataValueFactory. (I use _hda to
> distinguish it from _dat.) You also would need to add some lines to all
> the language-support scripts to support the new data type. I have
> already created a number of properties with my new data type, and it
> works very well. I invite you all to read a few articles to see how I
> have used the new type:
> The latter has a nifty demonstration of a table built entirely with an
> inline query. Notice how I find the names of three ancient kings and
> sort them in the order of their accession to the throne.
Very nice work. I have to check this in more detail to understand how all o=
this was done (and possibly to include it into 1.0 later on). I have some=20
ideas in mind how to deal with partly specified dates (e.g. year only, but =
day or month) without assuming a default, and I would like to merge this wi=
your solution on calendar conversion and date parsing. It might be that thi=
will have to wait until after 1.0 though.
> Now here is my problem: I want to use my new data type with the Simile
> implementation of the Timeline inline-query format. But I have a
> problem: Simile Timeline seems to want a numeric value in seconds; I
> want to supply a numeric value in days. Worse yet, Simile Timeline seems
> to want a 32-bit integer, whereas I have a 64-bit float. When I tried to
> specify the Timeline format, I got an unreadable broad band labeled with
> dates in recent history.
> Any insights you can give me would be greatly appreciated.
AFAIK Timeline can in principle also visualise times in other formats, or e=
to completely different kinds of numeric data. But the SMW-TimeLine adaptio=
scripts probably do not support any way of specifying this in wiki pages. B=
it could be done. See  for an example (currently broken for me, but work=
on other people's machines); anyway the employed data at  uses no second=
though the Timeline parameters for that are found in the HTML file.
=46or more Timeline support, David Huynh of MIT CSAIL is probably the perso=
> Terry A. Hurlbut
> PS: In case you're wondering, I of course release this file under your
> present licensing terms, which I believe are GPL version 2.0.
Thanks, it will surely be useful. (Though I think the GPL does not leave yo=
much choice on that anyway; unless of course you chose to not publish it at=
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
mak@... www http://korrekt.org