Markus: Thank you for your reply.
To answer your questions: 1. I cannot speak for any wiki user or administrator other than myself. But I strongly suspect that the way people worked around the problem was to change the sign of the specified time-zone offset. For instance: to apply the offset for MEZ, which is +1, a user could easily specify -1 and achieve precisely the desired result. Similarly, a user in New York, NY, USA would specify +5 instead of -5 for EST (or +4 instead of -4 for EDT). The problem is that this is the exact opposite of what a time-zone offset is supposed to be. The offset is the number of hours to be added to (+ sign) or subtracted from (- sign) UTC in order to get the time shown on the local clock. But I'm ninety-five-percent confident that people began to figure out that the way that SMW wanted its offsets handled was that the offset specified the number of hours to be added to (+ sign) or subtracted from (- sign) the /local clock/ in order to get the time shown on the UTC clock! A simple change of the sign allows consistent handling of all offsets, and allows one to annotate an offset according to its proper form. Thus, 14:00:00+1:00 will resolve to 13:00:00, as it should. And on this side of the pond, 17:18-4:00 will resolve to 21:18. 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. 3. Military time might be relevant to a wiki run by and for military personnel. It would also allow someone to reproduce the text of a military memorandum and annotate the date directly, rather than using the "pipe trick" to annotate a civilian time underneath the military. In any event, it occurred to me to annotate all time-zone monikers and time formats, in /anticipation/ of future demand. And as you observe, the extra code amounts to a few lines that does not make the code more complex. (Remember, though, that the specification of a military time-zone letter is mandatory to distinguish a military time from a year.) 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?) 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). 2. Support the "Old Style" system that was in use in the British Empire prior to the Calendar Act of 1752. In that system, dates used March 25, and not January 1, to start the year, and also used the Julian calendar. At least one wiki that I administer has articles on certain historical figures (generally astronomers and other scientists) that might have had their dates-of-birth given in Old Style. I'd like to be able to /annotate/ those Old Style dates directly and have them resolve appropriately to the New Style. The chief modification of this from traditional Julian dates is that any OS date between January 1 and March 25 needs to have its year increased by one, and /then/ have the Julian Day computed according to a Julian algorithm. The date would then be back-converted according to Gregorian rules, if that Julian day fell on or after the JD of October 15, 1582 (Gregorian). An example of OS usage would be this: "Here lies Thomas Jefferson, author of the Declaration of Independence, and of the statute of religious freedom, and founder of the University of Virginia. Born [[born::April 3, 1728 OS]]. Died [[died::July 4, 1826]]." 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. 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. 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. 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 > > > > ------------------------------------------------------------------------------ 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
