Discussion
Pegasystems Inc.
JP
Last activity: 15 Oct 2020 21:40 EDT
Datetime issue with Summer time in Japan (1948 ~ 1951)
Hi,
Recently a pretty weird issue was reported to me by customer. They have upgraded their Java version, and this has started to happen. The issue is, when end user entered the 2nd of May, 1948 for date of birth field, data got invalid and system threw an error. We've investigated this issue, and found out why. It is a very rare case, but in this post I am sharing the root cause for a reference.
1. Japan DST history
I don't think many people know about this, but DST (Daylight Saving Time), a.k.a summer time was actually once introduced in Japan in 1948, and clocks were advanced by an hour. The system lasted for only three years because total work hours ended up becoming one hour longer and workers complained that they were being exploited.
| No | Start | End | Notes |
|---|---|---|---|
| 1 | 2 May 1948 | 11 Sep 1948 |
|
| 2 | 3 Apr 1949 | 10 Sep 1949 |
|
| 3 | 7 May 1950 | 9 Sep 1950 |
|
| 4 | 6 May 1951 | 8 Sep 1951 |
|
2. System behavior
When DST starts or ends, clocks are turned forward or backward for an hour. That means, this time period is not supposed to exist. So, entering this non existent timestamp will lead to a system error. Be noted that this issue happens only for operators who have "Asia/Tokyo" or "JST" timezone. Other timezone holder (ex. "America/New_York") wouldn't face this issue.
For example, if you try to enter the 2nd of May, 1948, 00:01 for a DateTime field as below.
When you click "Save" button, system displays an error message as below.
In this case, the user is notified of the error message, and he can correct data on the spot, which I think is less problematic. However, if the field is Date or Text and after submission activity appends 00:00 to convert it into Datetime in the background, an internal error is thrown in the post processing. I would use Date type for DOB property, but some customer may use Datetime type to preserve timestamp for other usage.
3. What does it have to do with Java version?
The system went live long time ago and the issue was never detected. Why is this issue detected after Java version is upgraded? Per our investigation, in 2018, timezone data was updated to include this past DST in Java. Below is the quote from release announce of "tzdata 2018c". The changes are included from 10, 8u172, 7u181, 6u191 onward.
https://www.oracle.com/java/technologies/tzdata-versions.html
Changes to past time stamps Japanese DST transitions (1948-1951) were Sundays at 00:00, not Saturdays or Sundays at 02:00. (Thanks to Takayuki Nikai.)
To conclude, if your operators have Japan timezone, and if you are planning to use Java version that includes above update, and if you have a Datetime property that could host 1948 - 1951 timestamp data, discuss within your team how to avoid this issue.
Thanks,