From: Brian M. <br...@gr...> - 2009-01-18 02:57:31
|
> > Have you updated the XML import/export plugins to > support the changes? > > Have you updated the DTD? > > Good points. No, I haven't done those, but I'll put > it on the list. I may > need some assistance with that part... I'll take a > look. I'm not sure who the expert is on this. It certainly isn't me. But I do know that it is important. Feel free to holler at the list if you need help. > >> discussions with experts in genealogy dates, > >> and some hairy > >> details on the bug tracker. Basically, it boils > down to one > >> being able to > >> indicate that a date occurred in a year that > didn't > >> start on Jan 1, but on > >> a different starting day. Currently, the system > supports > >> "Jan1", "Mar1", > >> "Mar25", and "Sep1". These can > be > >> increased, but they are codes/symbols > >> rather than numeric offsets. > > > > This doesn't seem very scalable. Why didn't > you just use an offset? > > It wasn't clear to me if we needed the full range of > values for offsets, > or just a few. I thought it may also be the case that there > would be a > mapping from some key names (like "Mar25" or > "Rome") to offsets, so we > would need to store those mappings anyway. Finally, storing > "Mar25" rather > than the offset puts the focus on Mar25 rather than a count > and a date, > which might pose some problems when translating between > calendars, or leap > years. > > I also tried to make the text not look too much like a > date, so that it > won't be too confusing. If it were an offset, that > sounds like it would > have to parse like a date (but it could be done just the > way that I have > it, at least in English). > > In any event, the current system can be approximately both. > Currently, the > values in date.py are: > > NEWYEAR_JAN1 = 0 # codes > NEWYEAR_MAR1 = 1 > NEWYEAR_MAR25 = 2 > NEWYEAR_SEP1 = 3 > > But if we change those to: > > NEWYEAR_JAN1 = 0 # offset days > NEWYEAR_MAR1 = 59 > NEWYEAR_MAR25 = 83 > NEWYEAR_SEP1 = 243 > > This will be both a code (for now) or if you want to change > to a true > offset in the future, this will be approximately correct > (doesn't take > into account leap years, so maybe one day off). We can also > do this step > in a conversion in the future, if you wish. The code should > work either > way since Jan1 is the default and helpfully 0. We'd > just have to change > the parser to allow offsets in some form. > > Let me know. It sounds like you have thought it through. I was more curious than anything. With a complex feature like this, I think that readability should be the most important quality attribute. So please do what you think is most readable for other developers. ~Brian |