Timezone Support user/org/client level

Description

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.

Environment

None

Activity

Show:
Nicolas Micoud
August 13, 2015, 5:25 AM

Hi Norbert,
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 !

WDYT ?

Nicolas

Diego Ruiz
August 22, 2020, 1:53 PM

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.

Carlos Ruiz
September 1, 2020, 2:20 PM

I was doing some tests with and came up with this comment:
https://stackoverflow.com/a/32281019/1968443

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.

WDYT?

Nicolas Micoud
September 1, 2020, 2:49 PM

Hi,

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).

Regards,

Nicolas

Carlos Ruiz
September 3, 2020, 2:59 PM

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.

Using UTC would be the recommended approach - especially to manage multi-timezone users installations, because that way you avoid errors like which have had several historical causes, like the java timezone information outdated, or a mismatch between java vs javascript timezone management.

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.

Assignee

Unassigned

Reporter

Norbert Bede

Tested By

None

Components

Affects versions

Priority

Major
Configure