https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37952
--- Comment #8 from David Cook <dc...@prosentient.com.au> --- I think we'd need to very thoroughly test this change. * As a first change, why don't we do some code for capturing the user's timezone, setting the cookie, and then storing it in their session? There's no harm in doing that immediately, as it would be a very simple change to make. This can be pushed as a standalone change. (In prod, I don't think we'd want to allow users to change their timezone setting in the app, but in test it would be handy to be able to change your timezone for testing the below changes...) * A second step could be to just convert from the server TZ to the user's TZ for display. Since it's just display, bugs wouldn't have long-lasting consequences, and in many cases the converted times would probably be the same, although we could take some time to analyze this (I have a number of clients in different timezones than me). This could also be pushed following step one. * A third step... I suppose would be converting user's TZ to server TZ for storage. (In many cases, this will probably be the same or similar time, so any bugs should be minor.) * Fourth step would then be to convert from server TZ to UTC. (Hopefully by this point the main mechanisms have been tested and trialled in prod over time.) -- I think that I'd feel a lot more comfortable following a plan like that. Doing everything at once scares me. Trying to recover from bugs with a switch to UTC will be a really difficult challenge for people like me who live in timezones at the extreme end of variation from UTC (like +11:00, +14:00, -12:00). -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/