Date enhancements for GRAMPS 3.1

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Date enhancements for GRAMPS 3.1

Douglas S. Blank
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Brian Matherly
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Douglas S. Blank
[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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Gerald Britton-2
In reply to this post by Douglas S. Blank
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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

--
Sent from my mobile device

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Brian Matherly
In reply to this post by Douglas S. Blank
> > 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Gerald Britton-2
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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

DS Blank
On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Benny Malengier


2009/2/24 Doug Blank <[hidden email]>
On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Gerald Britton-2
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
<[hidden email]> wrote:

>
>
> 2009/2/24 Doug Blank <[hidden email]>
>>
>> On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <[hidden email]>
>> 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
>>> <[hidden email]> 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
>>> > [hidden email]
>>> > 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Date enhancements for GRAMPS 3.1

Benny Malengier


2009/2/24 Gerald Britton <[hidden email]>
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
<[hidden email]> wrote:
>
>
> 2009/2/24 Doug Blank <[hidden email]>
>>
>> On Mon, Feb 23, 2009 at 2:21 PM, Gerald Britton <[hidden email]>
>> 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
>>> <[hidden email]> 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
>>> > [hidden email]
>>> > 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel