DatePicker shows date - 1 when select date = 01/01/1900

[Focuszaa Funz]

Hi, community,

I identified in iDempiere 6.2 for dates < 1/1/1900, which get converted to a date -1DAY, e.g. the date 1/1/1900 gets converted to 31/12/1899. 

Before saving. 

After Saving.

when seeing from grid view it's correct 

I also checked on the database, it's correct but it shows on datepicker is = date- 1. 

if anyone has any ideas about this issue please let me know. 

[Focuszaa Funz]

larger pictures 

before saving 

after saving 

[Carlos Antonio Ruiz Gómez]

Hi, I found this issue very interesting  :-)

I was able to reproduce the issue trying to save in Test window, field Date -> july-20/1810 in demo.globalqss.com.

Behavior was like this - login with english language to System and open Test window:

1st time -> fill the date with 07/20/1810 and save

when saved the date changes to 07/19/1810 - checked database and in DB is july 19

2nd time -> change again the date to 07/20/1810 and save

now is saved correctly in database

Note demo.globalqss.com is running with Colombian timezone (UTC-5) and my browser is located in Germany (UTC+2)

The same issue doesn't happen in test.idempiere.org - or running locally in my eclipse, in these cases it works without problems.
Probably because in this case server and client have the same timezone (Germany).

After research I didn't arrive to a final conclusion, but it seems the issue is related to two factors:

1 - timezone difference between client (browser) and server

2 - there is a known java time shift in jan-1-1900, see for example these two links:

https://stackoverflow.com/questions/16409554/30-minute-error-in-java-date-calculation-in-year-1900-only

https://stackoverflow.com/questions/19542461/why-does-adding-minutes-to-1900-01-01-000000-results-in-a-change-in-seconds

So, from my debug session, somewhat like when processing a date from the browser, somehow it gets the browser timezone and adds a shift of 5h56m16s (can vary depending on the timezone), and then java makes the calculations parsing the date string and results in the shifting to the day before.

This sample code can illustrate the thing:

TimeZone.setDefault(TimeZone.getTimeZone("America/Bogota"));

SimpleDateFormat df = new SimpleDateFormat("yyyy.M.d.H.m.s.S", Locale.US);

df.setTimeZone(TimeZone.getTimeZone("UTC"));

System.out.println(df.parse("1900.1.1.4.56.16.0"));

System.out.println(df.parse("1899.12.31.4.56.16.0"));

System.out.println(df.parse("1810.7.20.4.56.16.0"));

The results are different depending on the timezone set in the first line, if I set America/Los_Angeles it gets a different result also wrong, if I set "Europe/Berlin" it gets correct in my case.

Regards,

Carlos Ruiz

El miércoles, 29 de mayo de 2019, 7:44:18 (UTC+2), Focuszaa Funz escribió:

larger pictures 

before saving 

after saving 

On Wednesday, May 29, 2019 at 12:34:19 PM UTC+7, Focuszaa Funz wrote:

Hi, community,

I identified in iDempiere 6.2 for dates < 1/1/1900, which get converted to a date -1DAY, e.g. the date 1/1/1900 gets converted to 31/12/1899. 

Before saving. 

After Saving.

when seeing from grid view it's correct 

I also checked on the database, it's correct but it shows on datepicker is = date- 1. 

[Focuszaa Funz]

Hi, Carlos,

Thank you so much for your help and explanation.

My iDempiere server is in AWS environment and it's in ap-southeast-1, my Database is on RDS service and it's in the same availability zone which is Singapore time. 

I have no problem in my iDempiere 5.1 but it happens in iDempiere 6.2, after testing by running 2 instances they point to the same DB instance.

1. iDempiere 5.1 

2. iDempiere 6.2 

Test in the same window and record : 

1. iDempiere 6.2 input 01/01/1900 then save, the Datepicker shows Date -1 = 31/12/1899. 

2. iDempiere 5.1 input 01/01/1900 then save, the Datepicker shows correctly Date = 01/01/1900.

I looked into time stamp on Record info 

- iDempiere 6.2 recorded timestamp = May 30, 2019, 5:22:05 PM SGT

- iDempiere 5.1 recorded timestamp = May 30, 2019, 4:52:23 PM SGT

You can see that iDempiere 6.2 (Java V 11.01) faster than iDempiere 5.1 (Java V 1.8.0_192) about 1:30:18 ( HH:MM: SS )

I think this issue is also relating with Java version following example case below,

https://stackoverflow.com/questions/33894054/timezone-differences-in-java-8-and-java-7

And here is release note that Java has been updating time zone of each version. 

https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html 

I'm still trying to fix this issue if you have any ideas please let me know, 

Thank you in advance. 

[Carlos Antonio Ruiz Gomez]

Hi, if it worked fine in previous versions then most probably it can be related to recent changes in zk, or java itself.

From my debug session going very very deep in the problem I noticed when I fill the datebox with 07201810 - the value passed through zk is something like "1810.7.20.4.56.16.0"  - so until some point the string is still july-20.

Then it arrives to org.zkoss.zk.au.AuRequest->parseType - line 108 (breakpoint here)

This calls org.zkoss.json.JSONs->j2d

and there the string is converted to a date with july-19

Looking at that code is where I found the usage of SimpleDateFormat with timezone UTC, converting that string to july 19 (the sample test code posted before).

BTW, you mentioned your server aws timezone - but that's not the important part, it depends on the timezone configured in the operating system server, for example in ubuntu the file /etc/localtime shows that info.

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Apr 24 18:22 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

Regards,

Carlos Ruiz

El 30/05/19 a las 11:37, Focuszaa Funz escribió:

--

[Focuszaa Funz]

Hi Carlos,

My bad.., I forgot to tell you that i already changed time zone on both application servers (5.1,6.2), they are the same time zone which is South East Asia- Singapore.

So, Thank you so much again for your explanation, i will try to check again tomorrow.

[Carlos Antonio Ruiz Gomez]

A bit more of research on this, found:
https://tracker.zkoss.org/browse/ZK-3527

This commit made a change on the timezone on JSONs (changed from zk
version 8.0 to 8.5)
https://github.com/zkoss/zk/commit/222d17d

Probably we need to adapt our code to that change.

Regards,

Carlos Ruiz


El 30/05/19 a las 14:59, Focuszaa Funz escribió:

[Focuszaa Funz]

Hi Carlos, 

After testing today, my previous test was wrong, The time in 6.2 and 5.1 instances had the same time and 6.2 wasn't faster than 5.1 as mentioned before.

I changed the timezone zone on my server from Singapore time to London time, the Date-picker shows the correct date.

Regards 

FCZ.