Hey folks Just looking for a quick consensus on passing dates to C4 modules. Some expect iso, some expect local format. memberentry.pl is currently not working because the date is double iso'ed... I suggest the coding guideline that scripts maintain the date in local syspref-defined format, and that all public methods in C4::* should expect dates to be passed in local format. So format_date_in_iso should be rare at the script level. comments ? -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
I suggest the coding guideline that scripts maintain the date in local syspref-defined I would have preffered to use iso in the code and format only for outputting, but let's go with the solution you suggest. The important
Ryan Higgins a écrit : thing is to have a single method to handle dates ! -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Paul POULAIN wrote:
I suggest the coding guideline that scripts maintain the date in local syspref-defined I would have preffered to use iso in the code and format only for outputting, but let's go with the solution you suggest. The important
Ryan Higgins a écrit : thing is to have a single method to handle dates !
I you choose local time, are you sure that scripts will behave correctly when there is time-shifting (several country such as France add and remove one hour one time per year) ? I do not look at the code, so I do not have any hints if the answer is yes or no. This is just a classical issue with local time. Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
Vincent Danjean <vdanjean.ml@free.fr> wrote:
Paul POULAIN wrote:
I suggest the coding guideline that scripts maintain the date in local syspref-defined I would have preffered to use iso in the code and format only for outputting, but let's go with the solution you suggest. The important
Ryan Higgins a écrit : thing is to have a single method to handle dates !
I would prefer ISO-format UTC, but also prefer a single method. I don't think the UK has one standard format, with opinion varying between N Mon YYYY and Day, Nth Month YYYY and so on, so I could forsee some of my servers having different settings and potentially confusing me when working to develop fixes on a remote server that doesn't happen on my test servers.
I you choose local time, are you sure that scripts will behave correctly when there is time-shifting (several country such as France add and remove one hour one time per year) ? I do not look at the code, so I do not have any hints if the answer is yes or no. This is just a classical issue with local time.
Isn't France itself in multiple timezones, once you include DOM-TOM? Also USA. Again, a classic problem with using local time internally. Will that cause us problems? Regards, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
Without intending to contradict your suggestion, the recent work this week by myself and several others moves in the opposite direction of passing only ISO date strings between modules. The main reason this makes sense is that scripts still need to be validating user input, regardless of format, before calling things like ModMember. A C4::Dates object provides validation functionality (via the regexp() function) to the script, so the script might as well do the conversion also. The problem of double-conversion can also positively be avoided by passing C4::Dates objects themselves rather than date strings. This should be the standard for new code. (Unfortunately, nothing in the old code does this yet.) For 3.2, we intend to return undef on invalid constructor argument(s) and make a sweep of the code to ensure scripts actually care whether or not their date string was valid. As it stands in 3.0, too many places just call format_date_in_iso($any_old_string). Thanks to Galen Charlton's help debugging C4::Dates, we have cleaned up a problem with multiple objects not receiving unique dataspace. I want to apologize to Paul, because I think he detected this very early on, and I didn't understand at that time what he was indicating. You should be able to verify now that it is fixed, and use any arbitrary number of objects. This clears the way for more widespread usage. The comments about timezones address a separate issue from the date *formats* supported by koha (iso, metric, us). C4::Dates does not affect anything to do with timezones. --joe atzberger LibLime * Open-Source Solutions for Libraries 888-564-2457 On Dec 15, 2007 3:12 PM, Ryan Higgins <ryan.higgins@liblime.com> wrote:
Hey folks
Just looking for a quick consensus on passing dates to C4 modules. Some expect iso, some expect local format.
memberentry.pl is currently not working because the date is double iso'ed...
I suggest the coding guideline that scripts maintain the date in local syspref-defined format, and that all public methods in C4::* should expect dates to be passed in local format. So format_date_in_iso should be rare at the script level.
comments ?
-- Ryan Higgins
participants (5)
-
Joe Atzberger -
MJ Ray -
Paul POULAIN -
Ryan Higgins -
Vincent Danjean