Message Boards Message Boards

3
|
7821 Views
|
4 Replies
|
4 Total Likes
View groups...
Share
Share this post:

A robust pre-processor for DateObject[] for use by the humanities

The current string input for DateObject[] has a number of issues:

First, if you try to enter a first century date, the result is a twentieth century date. So if you enter the traditional date for the destruction of Pompeii by Vesuvius, you get the wrong result:

In[2]:= DateObject["8/23/79"]

Out[2]= DateObject[{1979, 8, 23}, "Day", "Gregorian", -4.]

Second, the most popular date format is ambiguous: depending on the user's location, the order could be month/day/year or day/month/year. There is no way to specify the order beforehand:

Third, if the user wants to make a date object out of a century, such as "16th Century", DateObject[] does not work at all. Instead, you must use Interpreter[], which does the job but which requires an internet connection and can be very slow.

Fourth, when entering historical dates, the calendar type is assumed to be that which was in place at the time and location of the event. Thus, the date of the start of the Great Fire of London is given as September 2, 1666, which is understood to be a Julian Calendar date, since this calendar was in use in London at the time. Certainly, the date of the battle of Agincourt, 10/25/1415, is understood to be a Julian calendar date, since the Gregorian calendar was not introduced until 1582. However, DateObject[] assumes that both these dates are given for the Gregorian calendar [LongDash] the default is not even shown in the pod.

These issues render this function problematic for anyone who wants to rely on string input for the function, which is most people who might want to do historical research. (These issues are mostly moot for dates from the 19th century or later.)

I have made a package that fixes these problems:

  1. Any date that is entered with a year prior to 1582 will be assumed to be a date in the Julian Calendar.

  2. There will be a variable to specify the adoption year of the Gregorian calendar. This will default to 1582. The user can set this to the year for the country they are working with, such as 1752 for England and colonies.

  3. Dates with a two-digit year will be interpreted properly, as occurring in the first century

  4. Century specifications, such as 'XVI century' or 'Fourth Century BCE' will be interpreted properly.

  5. 'Trecento' and similar terms used in Italian Cultural History will be properly interpreted.

  6. AD, BC, CE, and BCE will all work.

  7. O.S. and N.S. (and variants) will work to designate Calendar type.

The package is attached to this post. A fuller explanation is provided in the other document.

It is my hope that this functionality will eventually make its way into Wolfram Language, replacing the existing string parser for the function. Other than not allowing '79' as a shortcut for '1979', the functionality in the package would have no effect on the typical usage for recent dates, and dates using proleptic Gregorian calendar (or Julian Dates) for astronomical computations.

Feedback is welcomed.

Thanks.

4 Replies

Thanks for the link, and to 'meet' you, so to speak. The people at Wolfram would profit from interacting with people like you. My own knowledge about these matters is rudimentary compared with the depth needed to do a complete job.

The primary task is getting scientists to recognize that there really is a problem that people in the humanities have to deal with. Pretending that the Gregorian calendar (and its equivalent, Julian Day) is the solution for everything only works for a limited number of applications. My hope is that my "show" rather than "tell" project will illustrate that it is easy enough to get the basics right for the humanities without making it difficult for the physicists and engineers to do their computations.

Hi George, I was very surprised and pleased to see your post on the topic of historical dates (and by extension, historical places). Two important and complex topics. I've so far only skimmed over your post and notebook but will get back to you with some detailed comments soon.

I've a particular interest in the topic since I was involved in an effort a few years ago to describe the research infrastructure needed to better tackle dates and places in particular for early modern scholars. You can read about this here (open access monograph). This in turn led to some (unfortunately incomplete – we ran out of time and funding) exploratory work on EM Dates and EM Places.

Though I've long maintained a dabbling interest in the WL I've never given myself the time to properly learn it and move beyond the beginner stage. One of my ideas was indeed to go to the Summer School with a plan to create a better historical date resource – but now I'm very glad to see that someone got there first!

best regards, Arno

POSTED BY: Arno Bosse

Thanks for the comments. Implementing year/month/day is easy enough, but I thought that, for consistency, I should also do '1847 May 22', and that would take a bit of extra work. Frankly, I was ready to move on to another project, so I punted.

What I wanted to do was to draw Wolfram's attention to the issues with DateObject[] with a string input. It's a mess once you get beyond the simple dates since 1800 or so. For example, I found that if you do DateObject["10/25/1415", CalendarType -> "Julian"], the function converts the date, which it assumes is according to the Gregorian calendar, and returns a date some nine days earlier. This is just wrong. It is my hope that there will be a revision to DateObject[] that will incorporate my code, with improvements.

I will try to revise the package to include the year/month/day and replace the existing package, in my copious spare time.

This definitely looks useful. I do have one bit of feedback: you expose the functions setDateOrderToDayMonthYear and setDateOrderToMonthDayYear and hide the variable workingDateOrder that they influence. That's fine by itself, but in that case I do think there needs to be a function setDateOrderToYearMonthDay. The yyyy-mm-dd format is prevalent in several countries and is also the ISO standard, so it really should be included here. I'd even argue it should be the default when starting the package, but that's up to your discretion.

POSTED BY: Sjoerd Smit
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract