Timezone Support user/org/client level

Ticket https://idempiere.atlassian.net/browse/IDEMPIERE-5093 is implementing new types Timezone and DateTime with Timezone. Not sure if is a complete solution for this, or it makes this ticket closer to solve.

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 https://idempiere.atlassian.net/browse/IDEMPIERE-4361#icft=IDEMPIERE-4361 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.

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

I was doing some tests with https://idempiere.atlassian.net/browse/IDEMPIERE-4361#icft=IDEMPIERE-4361 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?

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.