Julian Day Operability Feature

[GoogleCodeExporter]

This is a fantastic resource - let me start off with that.  I've started 
tinkering with it for our research project website, and it will be of great use.

An on going concern, however, is date precision and how SIMILE in general 
handles dates.  I have yet to come across any discussion of a distinction 
between Gregorian as date FORMAT and the Gregorian calendar implementation 
itself.  As an historian, this is obviously of some concern as the project is 
wrestling with dates c. 1400-c.1800 - right in the implementation window.

One solution which looks promising from our end in reconciling the haphazard 
and slow implementation of the Gregorian calendar has been to continue to use 
Julian Days as a kind of place-holder absolute. Not perfect, but given their 
use in Astronomical practices, at least they seem consistent.  Right now this 
means allowing users to geolocate an event, and then select the appropriate 
calendar for the event - Julian or Gregorian.  The database then stores both 
the date as text, but also the resolved Julian day, even if it is a Gregorian 
date.

I've been thinking about how SIMILE and TimeMap might work with Julian days 
while displaying calendrial information.  It is obviously an immense task as it 
strikes right to the heart of how SIMILE itself works.  What would be really 
useful is being able to select Julian or Gregorian as display options, have the 
dates rendered accordingly, and have them noted as to whether they are Julian / 
Gregorian 'fixed'.  The Julian Day number would act as an absolute integer for 
computation etc.  Right now we'll have to stick to just using formatted dates, 
and specify the calendar, but the thing is they won't plot correctly - 
especially in terms of days / weeks.  Years / decades precision is still really 
useful right now, but longer term it might be worth while thinking about 
absolute time measurement versus calendrical descriptions of time.

There are a few libraries / js work that has been done on this kind of stuff, 
and it might be useful to think about it for the next development of SIMILE & 
TimeMap
see

http://arc.id.au/Calendar.html
http://www.fourmilab.ch/documents/calendar/

these though don't also deal with the changes in the new year either - but 
that's another issue.

Hope this is food for thought!

Original issue reported on code.google.com by milner.m...@gmail.com on 13 Apr 2011 at 2:41

[GoogleCodeExporter]

I agree that this is an important issue for historians, and I'd love to see it 
addressed. But I'm marking this as "WontFix" for the moment, because it feels 
relatively specialized, and I know I won't have time to work on it in the near 
future.

However, I think it would be easier to implement than you think. You'd only 
need two new pieces of functionality, both of which could be added in a modular 
fashion (i.e. without changing core library code):

1. A date parser that could parse string versions of Julian dates to the 
appropriate Javascript Date object. It looks like Fourmilab's Calendar 
Converter could provide a substantial basis for this. This would be added as an 
extension to the Timemap.js library, probably as TimeMap.parsers.julian.

2. A labeler function for Timeline that could take a Javascript Date object and 
render it as a Julian date.

The tricky part in both of these instances is tying the date to the country in 
question. If you wanted a parser that could handle both Julian and Gregorian 
dates, for example, you'd need some way to indicate a Julian date (eg. "April 
14, 1500 (Julian)" or something) so that the parser could distinguish, as I 
don't think there'd be any way to differentiate otherwise (correct me if I'm 
wrong - I'm not an expert on the topic).

The main point here, though, is that Javascript *does* have an absolute date 
concept - the JS Date object uses the number of milliseconds before or after 
12:00am Jan 1, 1970 GMT 0. So all that's necessary is figuring out a good way 
of converting to and from text representations of Julian dates. I'm afraid, 
however, that I'll need to leave this as an exercise for the reader.

Original comment by nick.rab...@gmail.com on 13 Apr 2011 at 5:07

• Changed state: WontFix

[GoogleCodeExporter]

Hi Nick;

Thanks for this - no worries at all! I thought I'd throw it out there
because the timeline is really one of those great tools for historians, and
binding it to maps is gold. So it's already a fantastic tool!!

In putting it up there, perhaps someone with more coding experience that I
can write a parser for it.  Where it gets tricky on my end has to do with
large databases - I'm working on one right now.  Academic historians will
want precision, and perhaps with those links I provided someone will be up
to the task especially when dealing with dates that use JSONP or XML
sources.  It's not so much the Javascript, as the backends and processing of
the data.  Right now I've got things in MySQL with Php, so it's easy to
encode JSON and use AJAX etc with jquery / prototype etc.  It's Php's
handling of the dates as despite MySQL's support for dates 1000AD+.  Pear's
date object works well enough, but none of them are calendar specific - so
the trick comes in sequencing events with different calendars at the same
time.  

Thanks!

Original comment by milner.m...@gmail.com on 13 Apr 2011 at 5:47

[GoogleCodeExporter]

Note that you can load dates in Timemap.js using UNIX timestamps, e.g.:

{
  title: "My event",
  start: 1302717071368
}

So you could handle the dates on the server side - MySQL should be able to 
output timestamps for any date it stores - and the dates will display correctly 
in the timemap, even though the labels on the timeline will still be Gregorian.

Hope that helps -

Original comment by nick.rab...@gmail.com on 13 Apr 2011 at 5:54

[GoogleCodeExporter]

I've been thinking more about this.  While I appreciate the idea of the parser 
(it makes sense), Julian Days present a much more interesting structural issue 
for the entire Simile project in general - it'd be kinda like moving the house 
around the corner, rather than adding a new extension.  Though the milliseconds 
idea is interesting (I've thought about it), the issue comes down, as you say, 
to comparative dates and which calendar to use.  The interesting thing about 
Julian Days is that they remain constant throughout calendrical switching.

I've essentially adapted the hybrid parser to work, but it still converts the 
date into a javascript date object that is defaulted obviously to gregorian.  I 
can't seem to find any documentation anywhere on how the JS date object 
calculates (if at all) the julian-gregorian switch.  Php just skips over Oct 4 
1582 to Oct 15 1582 as far as I know. Of course the unix timestamp is useless 
for this stuff.

I'm using php to generate the JSON regardless for the timemap, but it doesn't 
really resolve the timeline issue of how banding is handled. 

What I'm getting at I suppose is that julian days would make much more sense as 
the underlying date format for all of Simile as they're just integers. Seconds 
/ hours are handled as decimal points which are easy enough to translate.  The 
sticking point of course is geolocating the julian day, since it, like our day, 
follows the earth around.  What would be needed is a way to declare a julian 
day in relation, say, to UTC, which would then allow leveraging of the usual 
date/time objects etc.  

I don't think it's a pretty specific issue - if done, the end result would be a 
timeline/map library that could handle different calendars, or at the very 
least alternate between them.  The banding on the timeline could be integer 
based (simplifying some of the coding I imagine).  You'd have to set the 
calendar as an option for the entire timemap itself as I don't know how you 
could have different bandings for different calendars with the way it's all 
laid out.  But you could have a drop down or something to select the calendar 
and reload the entire thing.  
Or another option would be two calendar bands using the same data, but in 
different calendars...

Anyhow - it's a great tool, I'm just thinking like a pre-18th century 
historian.  I've been tinkering with geo-locating calendars.  Most are 
straightforward, but don't get me started on 18th century sweden.

Original comment by milner.m...@gmail.com on 5 Jan 2012 at 4:58