To expand on Leon's suggestion, you could also provide some simple constants for often-used date/time formats, making it even easier for your users to invoke standard formatting.
David On Mon, Dec 23, 2013 at 9:45 AM, Leon Timmermans <faw...@gmail.com> wrote: > On Mon, Dec 23, 2013 at 12:48 PM, Shmuel Fomberg > <shmuelfomb...@gmail.com>wrote: > >> Hi Stephen. >> >> On Fri, Dec 20, 2013 at 2:32 AM, Stephen Patterson wrote: >> >> >>> I'm the maintainer of Finance::Bank::CooperativeUKPersonal, a module for >>> downloading UK bank statements. Part of the output from this module is a >>> statement date in dd/mm/yyyy (UK) format. As I've started using the module, >>> I'm considering changing this to ISO-SQL standard - yyyy-mm-dd. What's the >>> best way of communicating this change & managing things during changeover? >> >> >> Is changing the interface really worth it? >> If you already have users, they won't appreciate the cleanness of the new >> interface. they just want their code to work. >> So while I understand that you want to fix past mistakes, unless they are >> major and doing real harm, just leave them be. >> >> don't worry, next module you will be wiser and make other mistakes. :-) >> > > Some 35 years ago, the authors of make didn't want to change the tabs > based syntax of makefile because they already had a few dozen users, we're > still suffering for it. It shouldn't be done lightly, or often, but > sometimes it is for the better. > > In this particular case, I'm wondering if a date_format argument taking a > strftime/strptime string wouldn't make more sense. Why not have the user > choose what it wants. Also, it may be a good idea if it stays consistent > with the memorableDate argument. > > Leon > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
