I found this issue: https://idempiere.atlassian.net/browse/IDEMPIERE-167 from Hengsin but status is wont fix and i dont like that approach.
Goal: supporting client with multiple locations and users around world. User will able to enter data in his timezone - server store it in server time zone - ZK UI display proper time according to login user timezone.
I investigate other cloudbased software the result is:
Tasks (need gathering)
add timezone to ad_client, ad_org, ad_user - login sequence: user has defined zone (y = use it no - looking for org timezone (same verification as before) then go to client if nothing use client 0 sysconfig.
Record Info - improvement - user browse record date/time - When “me” or others create record
calendar/time field must consider (my time +/- timezone shift (store with system date.) - partially solved.
Sorry for the delay, lot of work ATM.
This enhancement could be done in 2 steps :
#1 : field - to display date/time according to user preference
#2 : reports (standard, Jasper and scheduler)
I will be on holiday next 2 weeks, and i won't be able to produce anything until september. I will try to create a patch for #1 and i could ask you to test it ?
For #2, i fear it will be more complex so, one thing at a time !
Triaged by Diego Ruiz, closed as a potential idea due to inactivity in 5 years.
If any of you guys is still interested or is working on it, please feel free to reopen the ticket with further details.
I was doing some tests with and came up with this comment:
Suggesting the best approach is to have the servers always in UTC.
So, I tested the patch
- as a proof of concept.
The patch changes this:
added to server.launch the string -Duser.timezone=UTC (this is the equivalent to set the servers in UTC, or we can simply add it to the JVM always to force such state)
after this is added - noticed the Created/Updated dates are saved correctly in UTC timezone
changed WRecordInfo to show the dates information with the current browser timezone
With a policy like this (always UTC in server/DB) the work would be focused just on the UI side:
to show the dates properly in the browser timezone or a user configurable timezone if that's preferred (like WRecordInfo, reports, etc)
and work on the WDatetimeEditor to allow capturing/displaying dates in the browser/user timezone and SAVING in the database always in UTC
That doesn't sound like a big work and it would solve this issue in a recommended way.
I cannot test here as the 6.2 doesn't has a ClientInfoEvent.getZoneId() method.
But reading the code I think I understand the idea and that shoud work ^^
Tell me if I'm wrong but to use it, each installation must :
execute a big script to update all date+time fields (calculate gap between current TZ and UTC)
update all plugins/reports/... so each date+time will be displayed in the correct timezone.
=> Does it sound feasible to have a SysConfig to activate the new system or not ? So implementors can choose when activate it (that should not block migration for future versions).
I think we don't need to force UTC on the server, our conversion must be something like, save the dates always on the server timezone (as is happening at this moment I think) - and display the date+time fields in the user/browser timezone.
So, what you said above (migrating old datetimes to new timezone) is not something new, it applies actually if you want to change the timezone of your server.