[Bug 17621] New: API: Should the 'update_on' Patron field really be a datetime?
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Bug ID: 17621 Summary: API: Should the 'update_on' Patron field really be a datetime? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: hector.hecaxmmx@gmail.com, jonathan.druart@bugs.koha-community.org, lari.taskula@jns.fi, martin.renvoize@ptfs-europe.com, tomascohen@gmail.com Depends on: 16276, 17607 Blocks: 17620 Bug #17607 highlighted that all other date fields in the Patron response are simply 'date', whereas update_on is a date-time (without a timezone). We should assess whether it's actually necessary for the update_on field to record the timestamp as opposed to just a date, and if it required we should ensure we record and return the timezone detail along with it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16276 [Bug 16276] When automatically deleting expired borrowers, make sure they didn't log in recently https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17607 [Bug 17607] Fix patron definition in Swagger https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17620 [Bug 17620] Fix format of date/data-times in Swagger definition -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|16276 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16276 [Bug 16276] When automatically deleting expired borrowers, make sure they didn't log in recently -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|hector.hecaxmmx@gmail.com | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #1 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Martin Renvoize from comment #0)
Bug #17607 highlighted that all other date fields in the Patron response are simply 'date', whereas update_on is a date-time (without a timezone).
We should assess whether it's actually necessary for the update_on field to record the timestamp as opposed to just a date, and if it required we should ensure we record and return the timezone detail along with it.
We already have quite a number of datetime fields in Koha, but until now we apparently did not care much about the timezones. What would make this a different one? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- The simple fact that it's a public facing api makes it different. We handle timezone internally on the server, but for api consumers if they're not made aware of the timezone then they cannot do such handling themselves ;) It's also pretty standard practice to format a datetime to conform to the RFC's (and swagger allows for this). The RFC's include timezone as part of the string. I am aware there's precedent for datetime and date level specificity in different fields. I'm just not aware why this field in the Patrons table is different to the other date fields in the patrons object. Namely, lastseen, dateenrolled, dateexpired, debarred. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|API: Should the 'update_on' |API: Should the |Patron field really be a |'updated_on' Patron field |datetime? |really be a datetime? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 --- Comment #3 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- It makes sense to me to have a datetime for this kind of info. You can easily imagine a script processing the patron modified the last X hours, instead of days. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=17651 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #3)
It makes sense to me to have a datetime for this kind of info. You can easily imagine a script processing the patron modified the last X hours, instead of days.
+1, I think it's also consistent with similar fields on other tables (items, issues, currency) and helps when trying to diagnose problems, say with a patron import script or similar. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- OK, I think my point here was more about the api returnter_capitadiscoverytnr field than the database field itself. a) If we're wanting to keep this as a datetime as opposed to a date without time then we really need to ensure we return a timezone along with it. b) The field name is misleading and non-standard for this sort of thing, 'updated_on' suggests a 'date' not a datetime.. 'updated' is a less specific term which commonly denotes a timestamp as opposed to a date. My point really is that the API should NOT simply reflect the database.. an API is meant to hide the data storage details and rather expose the 'objects' and 'methods' an api consumer can work with. Understanding of implementation details should not be required or indeed cared about by an api consumer. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Man I hate not being able to edit comments in bugzilla! s/returnter_capitadiscoverytnr/return/g No idea how that crap got into that string. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org