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. ... > > In other news: As I indicated to you earlier, my attempts to import my > own algorithms for Julian-day conversion to and from the Gregorian and > Julian calendars met with one failure after another. I start to wonder > whether PHP sets limits on the "depth" of function calls. (In other > words, how many levels deep can your function calls go before they start > returning FALSE or otherwise producing totally unpredictable results?) If so, then I would be concerned if your parsing code would reach such a limit. > 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. > > 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. > > 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. > > 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. Markus > > Temlakos > > Markus Krötzsch wrote: > > On Montag, 10. August 2009, Temlakos wrote: > >> Dear Markus and Fabian, > >> > >> The attached patch, when applied to the file SMW_DV_Time.php, will > >> accomplish three things: > > > > Great. Patch applied and committed to SVN. > > > >> 1. Correct the processing of time offsets. Before the patch, time > >> offsets were being misapplied. This created a great deal of confusion. > > > > I wished more people would file bugs ... I am sure this could have been > > fixed with the previous release. > > > >> 2. Add recognition of civilian time-zone monikers like GMT, UTC, WET, > >> CET, EET, MSZ, MSK, MSD--or, in the United States, EST, CST, MST, PST, > >> AKST, HAST, /et cetera/. > > > > This is very nice indeed. I wonder if people will start entering > > timezones in wikis. My guess is that most will still ignore this and > > silently assume that the "obvious" timezone applies. Should we have some > > configuration parameter to set a default timezone that is to be used? > > > >> 3. Add recognition of US military times. A US military time /must/ be > >> followed by a capital letter (other than J for Juliet). > > > > I wonder whether there is a demand for this, but I added it nonetheless. > > It does not seem to complicate the code much. > > > >> I had previously sent you an e-mail containing the code, but no good > >> automatic way to apply the code to the file. I created this patch with > >> the diff command, using options -a (enforced line-by-line comparison) > >> and -u (unified output). This is actually my first attempt to create a > >> patch file, so please let me know whether you can apply it or not. > > > > Yes, the patch worked well (only one minor issue due to an update that > > had happened since the patch was generated; easy enough to fix manually). > > > > Thanks, > > > > Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
