Talk:Calendar
Switch-over Complexity
Surely the date of switchover between Julian and Gregorian calendars is locale specific? For example, getting the rules right for Sweden is… “interesting” given that they tried to do the switch slowly, got distracted by a war, and then decided to switch the rest of the way at once. –Donal Fellows 13:53, 31 May 2011 (UTC)
Maybe a the switch over date should be an argument, defaulting to the British date of switch? I am also a bit curious as to what dating system the International Astronomical Union use. Maybe there is standard for year/date definitions in BCE and CE?
Or... Another task could be to calculate the locale date and time, based on latitude, longitude, (altitude?) AND date. Ouch... to tough for me.
NevilleDNZ 22:45, 4 June 2011 (UTC)
- Conceptually, this would require a data structure which may be conceptualized as database table where the primary key was a polygon (a country's polygon) and a time interval (a time interval where that polygon defines that country's boundary). The table would also have to have a bit which indicates whether that time interval and polygon corresponds to the Julian or Gregorian calendar. All that you have to do to populate this table is find a list of all country boundaries as latitude/longitude polygons as well as how that has changed with each war or treaty settlement that has changed a country's boundary. And note that the algorithm which uses this data structure might have to return multiple values (when a border was in dispute during a region of time where one side of the border was Gregorian and the other side was Julian). An issue, of course, is that historical country boundaries might not always exactly correspond to anything we can currently unambiguously assign a latitude and longitude to (for example: when a river was the boundary -- rivers are wide and can move somewhat over the course of a century). On the other hand, this data structure can be considerably simplified where both sides of a border were using the same calendar. Nevertheless, I am not aware of any such list, and I think that this sounds like a huge historical research project. But the programming itself sounds relatively trivial (at least in comparison). --Rdm 18:44, 6 June 2011 (UTC)
Improving the task description
The task description includes these statements:
- Test the calendar by generating a calendar for the year 1969 on a line printer of the time with a width of 132 characters.
- Ideally the program will generate well formatted calendars for any page width from 20 characters up.
- Kudos (κῦδος) for routines that also correctly transition from Julian to Gregorian calendar in September 1752.
While generating a particular year is fine, a Real Programmer would not have written their calendar generator to handle arbitrary widths of display. Instead, it would have either produced for 132-char wide line printers or 80-char wide terminals. In this day and age, nobody's got line printers any more so formatting for an 80-char terminal is what we must put up with. Given that, I propose that the task should state that the calendar should be tested by generating a calendar for the current year suitable for an 80-column device. Adaptation to other widths, other years and other languages are all to be extra-credit items. –Donal Fellows 08:36, 4 June 2011 (UTC)
- Note also that the 132-column requirement would fit entirely within the scope of the dual CALENDAR task. :-) –Donal Fellows 08:47, 4 June 2011 (UTC)
Ruby incomplete?
The Ruby example has a template over it calling it "incomplete" because it doesn't print variable widths. But the task says "ideally", which suggests to me that it is optional. Fwend 16:04, 5 June 2011 (UTC)