Markus: Thanks for writing back. My responses appear below.
Markus Krötzsch wrote: > On Dienstag, 11. August 2009, Temlakos wrote: > ... > > >> 2. I hadn't thought of selecting a default time-zone moniker. I assume >> that this would be a new global variable to add to SMW_Settings.php, >> with the understanding that one would override this in >> LocalSettings.php. If I might suggest: Let's ask the SMW user community >> whether they would benefit from something like that. On my wiki, the >> times we're going to annotate will, for the most part, be times for >> special events. Those events will not be local to the time zone of the >> wiki; at a minimum they'll be in a region spanning four time zones >> (i.e., the United States of America), and at maximum they'll be >> worldwide (including events held in the UK, Continental Europe, >> Australia, etc.). So we'll use time-zone monikers for that, and might >> routinely be using a variety of monikers in our work. >> > > Even more than about input I was concerned about output. If users now use the > correct timezone in inputs, then all browsing and query interfaces will > display a plain timezone value without any readable timezone moniker or even > offset. This might be somewhat confusing. > Perhaps. But the browsed and queried values will be normalized to UTC. This would be entirely appropriate for querying events in sequence. Astronomers invented the Julian Day convention for that very reason: to be able to define a position in a sequence and even do simple arithmetic to count the days, and even the hours, between astronomical events. > If so, then I would be concerned if your parsing code would reach such a > limit. > Well, the parsing code was never a problem, because the parsing itself never had anything similar to recursive function calls. The problem probably lay in repeated calls to functions that called other functions in order to return years in different calendar models. Worse yet, my original Gregorian back-conversion function made repeated calls to auxiliary functions that were supposed to return Julian days for hypothetical beginnings of the year or month. The algorithm produced by you and Fabian avoided that problem, and adapting your algorithm to produce an accurate Julian day was simplicity itself. By now you might have received the patch containing my Old Style implementation. Now I can be confident that I can support various calendar models, and convert between and among them. > >> So: Now that you've actually applied the patch, I'm going to concentrate >> on modifying your code in createJD() and JD2Date() so that the Julian >> day involved is the "real" Julian day appropriate to the Gregorian or >> proleptic Gregorian year. That will be my first step toward implementing >> the Julian calendar as an alternative model. My goals are these: >> >> 1. Support the treatment of all dates prior to October 15, 1582 >> according to Julian calendar rules--except for your solution for dates >> before 4713 BC(E). >> > > Will there be a way of explicitly selecting Gregorian or Julian model? There > should be a reasonable default, but adoption of the new calendar did not > happen at the same time everywhere, so it might be convenient to give some > dates in Julian style even if the Gregorian calendar was already common in > other places. > At present the default cutoff date is the date that Pope Gregory IX proclaimed his new calendar. I would certainly like to make an explicit suggestion at input, but at the moment I cannot think of any symbol that anyone typically uses to indicate a thing like that. > > >> 2. Support the "Old Style" system that was in use in the British >> Empire prior to the Calendar Act of 1752. >> > ... > >> This model might not require internationalization of its symbol to >> languages other than English. The reason is that most historians who >> wrote in other languages, probably used the Gregorian calendar when >> appropriate to give even an Englishman's date of birth, flourishing, or >> death. >> > > Yes, that sounds reasonable. > That has now been done, and it works. > >> 3. Support the Hillel II calendar, for the benefit of wiki >> administrators in the Republic of Israel or other worldwide Jewish >> communities. >> >> 4. Support the Biblical calendar, according to hints contained in the >> Hebrew Bible (Old Testament) and clarified by Floyd Nolen Jones in his >> work, /The Chronology of the Old Testament/. That's primarily for the >> benefit of my own wiki, but I /have/ had people ask me privately to >> support that calendar model. >> > > You are the developer. I won't object unless it makes things significantly > more complex, larger or slower. > Thank you. I have one algorithm for the Hebrew calendar, that I know is in the public domain. That does, however, use a lot of recursion during back-conversion, so if I can find another algorithm, I'd rather use that. The Biblical calendar also uses astronomical predictors for the Jerusalem equinox and the new moon. The reason: It is an observed calendar, not a calculated calendar. One can certainly back-calculate astronomical observations with more than reasonable accuracy, so an algorithm is possible. But it is necessarily complex. You'll see when you receive the patch. > >> And that's just for the calendar models. I still intend to >> internationalize calendar-model and am/pm symbols, and then to re-create >> my "tooltip displays" from my custom datatype. I also have decided to >> accept your suggestion for specifying the calendar model as part of the >> DB Keys. In the version I'm working with, that means overwriting the >> getUnit() function to return the preference. >> > > I see. I would have preferred to put these defaults into the DBvalues string > instead of into the unit. The reason is that the unit, in principle, could be > used to determine incomparability of entries. For example, when searching for > lengths above 1km, the database cannot do much about an entry stored in > miles. > If this was implemented this way (which I think it is not currently), then > dates in different calendar models would be incomparable without need. An > alternative would be to extend the string format of a date to include such > default settings, but to still compute the numerical value using the current > scheme with the uniform transformation to proleptic Gregorian. > > It would still be nice if calendar models would work like units in the > interface, especially if one could change the calendar model used for > displaying query results (using the "?property # format" notation). Maybe it > would even be useful to allow a similar default output/overriding with > timezone monikers. > > > Times are hard indeed. > I'll need to study that DBvalues string you mentioned. The most difficult part of the development will probably be to transfer all my code to a new version of the file. Recall that my attempt simply to rewrite parseXSDValue($value,$unit) as parseDBKeys($args) ended in pages that "hung" when trying to load. Obviously something was wrong with that custom-type code--but what? That is why I sought to develop all this extra support in the standard datatype first, and /then/ reimplement it in the later version of the script. I have always sought to be able to specify a calendar abbreviation during a query and to have all returned dates appear in the specified calendar model. Also: for the original SMWHxDateValue, I developed a "tooltip dialog" as the output of getShortWikiText($linked), so that a reader could see at a glance how the date appeared in each of two or three models. (One thing that Ihave noticed is that if any numerical value appears in more than three units, only the first three will display, because whenever one tries to "scroll" through a longer list of values in various units, the dialog balloon disappears.) Recall that the Julian Day is the standard for interconvertability. Thus all dates are comparable to all other dates, because one need only compare the Julian Day. Furthermore, I intend storing different printout values for different models, as I did originally. Do you wish to retain a proleptic Gregorian display to run side-by-side with a Julian calendar display? If so, I can store a set of year, month, and day values for Julian as well as for Gregorian dates. I hadn't thought of doing that, but I can well understand the need for Julian dates that come later than the day of proclamation. Temlakos ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
