Re: [SMW-devel] SMW_DV_Time.php Time zone monikers and US military time

[Temlakos <tem...@gm...>]

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