search

girzel / ebdb

An EIEIO port of BBDB, Emacs' contact-management package
67 stars 12 forks source link

[Suggestion] make it possible to change the date format for anniversaries #88

Closed ecraven closed 4 years ago

ecraven commented 4 years ago

Anniversaries can be year+month+date or month+date (thanks for that flexibility). They are always shown as "Month Day, Year" or "Month Day". It would be nice if that were somehow adjustable, many locations do not in fact put the year before the day (but the other way around, Day Month). Thanks for any thoughts on this.

girzel commented 4 years ago

Yup, the present code is basically still at the "get it working" stage.

Would you be okay with a single defcustom that controls how all anniversaries are displayed? Would you have any need to specify different format strings for different anniversary instances?

The anniversary field also has a "calendar" slot, so that, in theory, you could add anniversaries in the buddhist calendar, or what have you. That isn't actually used anywhere in the code right now. Maybe it would be important to allow different format time strings for different calendars... hmmm...

ecraven commented 4 years ago

Yup, the present code is basically still at the "get it working" stage. Would you be okay with a single defcustom that controls how all anniversaries are displayed? Would you have any need to specify different format strings for different anniversary instances?

For me, that would definitely be fine (though you have two cases, anniversaries with year and those with year nil [probably things like namedays]). Not sure whether this is feasible, but maybe one defcustom for day/month (where you can use some escapes, to use full month name, short name, number with leading zero or plain number), and an extra defcustom for the year (and some way to specify whether the year should come before or after the month/day group).

The anniversary field also has a "calendar" slot, so that, in theory, you could add anniversaries in the buddhist calendar, or what have you. That isn't actually used anywhere in the code right now. Maybe it would be important to allow different format time strings for different calendars... hmmm...

Given emacs' excellent support for different calendars, this is definitely an interesting idea.. things like the Yahrtzeit cannot be written correctly in the gregorian calendar, afaik (https://en.wikipedia.org/wiki/Bereavement_in_Judaism#Annual_remembrances).

Thanks for thinking about this!

Greetings, Peter

girzel commented 4 years ago

Yes, I'd also come to the conclusion that we'd need a "double" format string, one for with-year, one for without-year. I'll do that first.

The calendar question is fascinating to me, and I'd really like to have EBDB support the full range of uses. My wife is Chinese, and I'd like to be able to put her lunar-calendar birthday into the system, and have it display correctly, for example. I'm afraid I didn't do all the necessary research to begin with, however, and just stuck a "calendar" slot into the class without really thinking through how it would all shake out. I will figure it out, but it just means that some code might have to be re-thought and re-written to make it work correctly.

Anyway, I'll do a simple defcustom first.

ecraven commented 4 years ago

Yes, I'd also come to the conclusion that we'd need a "double" format string, one for with-year, one for without-year. I'll do that first.

Maybe it would be best to just have to defcustoms, one for year-month-day, one for month-day, and no extra handling for pre- or postfixing the year.

The calendar question is fascinating to me, and I'd really like to have EBDB support the full range of uses. My wife is Chinese, and I'd like to be able to put her lunar-calendar birthday into the system, and have it display correctly, for example. I'm afraid I didn't do all the necessary research to begin with, however, and just stuck a "calendar" slot into the class without really thinking through how it would all shake out. I will figure it out, but it just means that some code might have to be re-thought and re-written to make it work correctly.

I heartily recommend Calendrical Calculations, if you haven't read that yet, a superb book for all things calendar!

Greetings, Peter