One “Quite Interesting” issue that came up in the development of the English Heritage timeline project was the handling of dates. You might think that a Timeline Event item would have, among its fields, a field for “start date” and a field for “end date”, just like the equivalent fields on an “Event” item type (which is used to store data about events and exhibitions at English Heritage properties):
However, we can’t store a date before January 1 1753 in a field like this (because the underlying database data type, a SQL Server DateTime, doesn’t support it). And even if we could, we couldn’t manipulate a date before 1 AD in our .NET code, because the .NET Framework DateTime struct doesn’t support that. The historical reach of English Heritage extends back to the Neolithic, so we’re going to need to plot timeline events such as the construction of Stonehenge or Julius Caesar’s landing in Britain, neither of which have dates we can store in a single item field or even manipulate as DateTimes in code. There’s also the issue of whether the date is specified in the Julian or Gregorian calendar – when plotting dates in English History in the 18th century you need to be sure that Date A is using the same Calendar as Date B otherwise you’re going to get confused about how where exactly they go and how much room they take up on the timeline. Great Britain switched from the Julian to the Gregorian Calendar in September 1752.
We got round this potential nest of confusion by using multiple (non-date) fields to store different parts of the information about a date:
We then use integers only to move date information around in the system, or perform date calculations to work out intervals or whether one event overlaps another. Here’s the JSON representation of an event:
The two large integers (which in this case happen to represent the same day) are the Julian Day Number representation of the date. A Julian day is a simple numerical representation of a date, without reference to a particular calendaring system other than the single “zero day” used to anchor the Julian Day numbering in time. The date we refer to as 26 May 1940, Gregorian Calendar, is Julian Day 2429776 – which is 2429776 days since January 1, 4713 BC Greenwich noon, Julian proleptic calendar.
The C# code on the server that generates the JSON and the JavaScript in the browser that generates the UI then just need to deal with integers.
Another advantage of entering a date as a series of separate fields is that the editor of the timeline can convey how precise the date is. Any datetime field is as precise as any other, but sometimes the exact date isn’t known – you might just know the month or the year, especially for events in the distant past. With a single datetime field you can’t convey the fact that when you say “January 1, 410: End of Roman Rule in Britain” you mean “about 410” but when you say “January 1 1973: Britain joins EEC” you really do mean the 1st January exactly. A datetime field on its can convey a false sense of accuracy.In our implementation you can leave the day and/or the month field blank. The string representation of the date will be generated to match (e.g. if the “day” field is left blank the string will be “May 1940” and if both day and month are left blank the string will just be “1940”).
The Timeline Event will always have a precise Julian Day associated with it, for plotting and calculation purposes – but we can convey how precise that date is.
