From: Douglas S. B. <db...@cs...> - 2009-01-17 16:39:13
|
Developers, I've finished the last big goals that I had for the new 3.1 release: added full support for "slash" dates, and implemented the new-year-day other than Jan1 changes. The first was easy: just need to add slash-date support in the date editor. The second was pretty difficult and involved changes in the database (made last year), 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. The date formatter, displayer, and GUI editor have all been adapted to handle dates with a new form. The form allows the new-year-day code to be included in parens right after a Calendar name (or instead of the calendar name). For example: * Jan 23, 1749 (Julian,Mar25) * Feb 15, 1702 (Mar1) All of this is documented here: http://www.gramps-project.org/wiki/index.php?title=Dates Please let me know if you have any problems, or comments. The forms "Jan1", "Mar1", "Mar25", and "Sep1" are completely arbitrary and could be something else. Let me know if you have better ideas. -Doug |
From: Brian M. <br...@gr...> - 2009-01-17 23:14:46
|
Doug, > I've finished the last big goals that I had for the new > 3.1 release: added > full support for "slash" dates, and implemented > the new-year-day other > than Jan1 changes. This sounds like a complicated feature. Thanks for taking it on. > The first was easy: just need to add slash-date support in > the date editor. > > The second was pretty difficult and involved changes in the > database (made > last year), Have you updated the XML import/export plugins to support the changes? Have you updated the DTD? > 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? > The date formatter, displayer, and GUI editor have all been > adapted to > handle dates with a new form. The form allows the > new-year-day code to be > included in parens right after a Calendar name (or instead > of the calendar > name). For example: > > * Jan 23, 1749 (Julian,Mar25) > * Feb 15, 1702 (Mar1) > > All of this is documented here: > > http://www.gramps-project.org/wiki/index.php?title=Dates Nice write up. Very helpful. > Please let me know if you have any problems, or comments. > The forms > "Jan1", "Mar1", "Mar25", and > "Sep1" are completely arbitrary and could be > something else. Let me know if you have better ideas. > > -Doug ~Brian |
From: Douglas S. B. <db...@cs...> - 2009-01-18 01:19:26
|
[snip] > 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. >> 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. >> The date formatter, displayer, and GUI editor have all been >> adapted to >> handle dates with a new form. The form allows the >> new-year-day code to be >> included in parens right after a Calendar name (or instead >> of the calendar >> name). For example: >> >> * Jan 23, 1749 (Julian,Mar25) >> * Feb 15, 1702 (Mar1) >> >> All of this is documented here: >> >> http://www.gramps-project.org/wiki/index.php?title=Dates > > Nice write up. Very helpful. Thanks, -Doug >> Please let me know if you have any problems, or comments. >> The forms >> "Jan1", "Mar1", "Mar25", and >> "Sep1" are completely arbitrary and could be >> something else. Let me know if you have better ideas. >> >> -Doug > > ~Brian |
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 |
From: Gerald B. <ger...@gm...> - 2009-02-23 19:21:52
|
Doug -- I see you've been working on date.py recently. I ran into an odd situation with it where I had a date instance, say "mydate" and I wanted to concatenate the string form of the date with some text, say "birth date". So I naively coded something like: print mydate + '- birthdate' However this fails, since the __add__ method in date.py currently only accepts an integer, IIRC. It's probably easy to test for adding a string and returning the concatenation of the string format of the date and the string supplied to the method. If you're still working on the module, I thought you might like to make the addition. If not, I'm happy to do it. On Sat, Jan 17, 2009 at 8:57 PM, Brian Matherly <br...@gr...> wrote: >> > 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 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Gerald Britton Sent from: Don mills On Canada. |
From: Doug B. <dou...@gm...> - 2009-02-23 23:20:37
|
On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <ger...@gm...>wrote: > Doug -- I see you've been working on date.py recently. I ran into an > odd situation with it where I had a date instance, say "mydate" and I > wanted to concatenate the string form of the date with some text, say > "birth date". So I naively coded something like: > > print mydate + '- birthdate' > > However this fails, since the __add__ method in date.py currently only > accepts an integer, IIRC. > The date __add__ method can take an integer or a tuple (y, m, d). But, yes, feel free to make it return a string repr in that situation. -Doug > > It's probably easy to test for adding a string and returning the > concatenation of the string format of the date and the string supplied > to the method. If you're still working on the module, I thought you > might like to make the addition. If not, I'm happy to do it. > > On Sat, Jan 17, 2009 at 8:57 PM, Brian Matherly > <br...@gr...> wrote: > >> > 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 > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > -- > Gerald Britton > Sent from: Don mills On Canada. > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2009-02-24 09:20:34
|
2009/2/24 Doug Blank <dou...@gm...> > On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <ger...@gm...>wrote: > >> Doug -- I see you've been working on date.py recently. I ran into an >> odd situation with it where I had a date instance, say "mydate" and I >> wanted to concatenate the string form of the date with some text, say >> "birth date". So I naively coded something like: >> >> print mydate + '- birthdate' >> >> However this fails, since the __add__ method in date.py currently only >> accepts an integer, IIRC. >> > > The date __add__ method can take an integer or a tuple (y, m, d). But, yes, > feel free to make it return a string repr in that situation. > I would not do this. The + to add strings is not translatable to right to left languages, so people should do a variable replacement instead anyway. So why support the addition of strings if it may not be used? Benny > > > -Doug > > > >> >> It's probably easy to test for adding a string and returning the >> concatenation of the string format of the date and the string supplied >> to the method. If you're still working on the module, I thought you >> might like to make the addition. If not, I'm happy to do it. >> >> On Sat, Jan 17, 2009 at 8:57 PM, Brian Matherly >> <br...@gr...> wrote: >> >> > 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 >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by: >> > SourcForge Community >> > SourceForge wants to tell your story. >> > http://p.sf.net/sfu/sf-spreadtheword >> > _______________________________________________ >> > Gramps-devel mailing list >> > Gra...@li... >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > >> >> >> >> -- >> Gerald Britton >> Sent from: Don mills On Canada. >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Gerald B. <ger...@gm...> - 2009-02-24 14:00:12
|
I would add it because it is idiomatic Python. e.g. I can always say: a = 'foo' b = a + 'bar' and get 'foobar' assigned to b. It just so happens that if a is a date instance it fails. date.py knows how to add integers to dates. Adding another overloaded operation is no big deal. I get your point about right to left languages and string ops, but then the standard syntax fails in those cases as well, does it not? On Tue, Feb 24, 2009 at 4:20 AM, Benny Malengier <ben...@gm...> wrote: > > > 2009/2/24 Doug Blank <dou...@gm...> >> >> On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <ger...@gm...> >> wrote: >>> >>> Doug -- I see you've been working on date.py recently. I ran into an >>> odd situation with it where I had a date instance, say "mydate" and I >>> wanted to concatenate the string form of the date with some text, say >>> "birth date". So I naively coded something like: >>> >>> print mydate + '- birthdate' >>> >>> However this fails, since the __add__ method in date.py currently only >>> accepts an integer, IIRC. >> >> The date __add__ method can take an integer or a tuple (y, m, d). But, >> yes, feel free to make it return a string repr in that situation. > > I would not do this. > The + to add strings is not translatable to right to left languages, so > people should do a variable replacement instead anyway. > So why support the addition of strings if it may not be used? > > Benny > >> >> >> -Doug >> >> >>> >>> It's probably easy to test for adding a string and returning the >>> concatenation of the string format of the date and the string supplied >>> to the method. If you're still working on the module, I thought you >>> might like to make the addition. If not, I'm happy to do it. >>> >>> On Sat, Jan 17, 2009 at 8:57 PM, Brian Matherly >>> <br...@gr...> wrote: >>> >> > 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 >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > This SF.net email is sponsored by: >>> > SourcForge Community >>> > SourceForge wants to tell your story. >>> > http://p.sf.net/sfu/sf-spreadtheword >>> > _______________________________________________ >>> > Gramps-devel mailing list >>> > Gra...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> > >>> >>> >>> >>> -- >>> Gerald Britton >>> Sent from: Don mills On Canada. >>> >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>> CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source code: >>> SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > -- Gerald Britton Sent from: Don mills On Canada. |
From: Benny M. <ben...@gm...> - 2009-02-24 14:13:16
|
2009/2/24 Gerald Britton <ger...@gm...> > I would add it because it is idiomatic Python. > > e.g. I can always say: > > a = 'foo' > b = a + 'bar' > > and get 'foobar' assigned to b. It just so happens that if a is a > date instance it fails. date.py knows how to add integers to dates. > Adding another overloaded operation is no big deal. > > I get your point about right to left languages and string ops, but > then the standard syntax fails in those cases as well, does it not? Not sure as I did not look in the code, but for the standard way, only a __str__ is needed, to cast it to string. _("%(date)s birthdate") % {'date': mydate} Benny > > > On Tue, Feb 24, 2009 at 4:20 AM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2009/2/24 Doug Blank <dou...@gm...> > >> > >> On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton < > ger...@gm...> > >> wrote: > >>> > >>> Doug -- I see you've been working on date.py recently. I ran into an > >>> odd situation with it where I had a date instance, say "mydate" and I > >>> wanted to concatenate the string form of the date with some text, say > >>> "birth date". So I naively coded something like: > >>> > >>> print mydate + '- birthdate' > >>> > >>> However this fails, since the __add__ method in date.py currently only > >>> accepts an integer, IIRC. > >> > >> The date __add__ method can take an integer or a tuple (y, m, d). But, > >> yes, feel free to make it return a string repr in that situation. > > > > I would not do this. > > The + to add strings is not translatable to right to left languages, so > > people should do a variable replacement instead anyway. > > So why support the addition of strings if it may not be used? > > > > Benny > > > >> > >> > >> -Doug > >> > >> > >>> > >>> It's probably easy to test for adding a string and returning the > >>> concatenation of the string format of the date and the string supplied > >>> to the method. If you're still working on the module, I thought you > >>> might like to make the addition. If not, I'm happy to do it. > >>> > >>> On Sat, Jan 17, 2009 at 8:57 PM, Brian Matherly > >>> <br...@gr...> wrote: > >>> >> > 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 > >>> > > >>> > > >>> > > ------------------------------------------------------------------------------ > >>> > This SF.net email is sponsored by: > >>> > SourcForge Community > >>> > SourceForge wants to tell your story. > >>> > http://p.sf.net/sfu/sf-spreadtheword > >>> > _______________________________________________ > >>> > Gramps-devel mailing list > >>> > Gra...@li... > >>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > >>> > > >>> > >>> > >>> > >>> -- > >>> Gerald Britton > >>> Sent from: Don mills On Canada. > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, > >>> CA > >>> -OSBC tackles the biggest issue in open source: Open Sourcing the > >>> Enterprise > >>> -Strategies to boost innovation and cut costs with open source > >>> participation > >>> -Receive a $600 discount off the registration fee with the source code: > >>> SFAD > >>> http://p.sf.net/sfu/XcvMzF8H > >>> _______________________________________________ > >>> Gramps-devel mailing list > >>> Gra...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, > >> CA > >> -OSBC tackles the biggest issue in open source: Open Sourcing the > >> Enterprise > >> -Strategies to boost innovation and cut costs with open source > >> participation > >> -Receive a $600 discount off the registration fee with the source code: > >> SFAD > >> http://p.sf.net/sfu/XcvMzF8H > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > > > > > > > -- > Gerald Britton > Sent from: Don mills On Canada. > |
From: Gerald B. <ger...@gm...> - 2009-01-18 03:29:17
|
Don't know if you were aware that the calendar.py module has some bugs. I have a new one almost ready to go that supports some additional calendars and fixes the bugs. On 1/17/09, Douglas S. Blank <db...@cs...> wrote: > Developers, > > I've finished the last big goals that I had for the new 3.1 release: added > full support for "slash" dates, and implemented the new-year-day other > than Jan1 changes. > > The first was easy: just need to add slash-date support in the date editor. > > The second was pretty difficult and involved changes in the database (made > last year), 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. > > The date formatter, displayer, and GUI editor have all been adapted to > handle dates with a new form. The form allows the new-year-day code to be > included in parens right after a Calendar name (or instead of the calendar > name). For example: > > * Jan 23, 1749 (Julian,Mar25) > * Feb 15, 1702 (Mar1) > > All of this is documented here: > > http://www.gramps-project.org/wiki/index.php?title=Dates > > Please let me know if you have any problems, or comments. The forms > "Jan1", "Mar1", "Mar25", and "Sep1" are completely arbitrary and could be > something else. Let me know if you have better ideas. > > -Doug > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Sent from my mobile device |