OaIdl.DATE(Date javaDate) sets wrong date in some cases

[eranl]

1. Version of JNA and related jars: 5.12.1

2. Version and vendor of the java virtual machine:
   IMPLEMENTOR="Oracle Corporation"
   JAVA_VERSION="17.0.1"

3. Operating system: Windows 7

4. System architecture (CPU type, bitness of the JVM): x86_64

5. Complete description of the problem:
   When com.sun.jna.platform.win32.OaIdl.DATE(Date javaDate) is called with a javaDate whose time part converted to local time is between midnight and 1am, while DST (60-minute offset) is on, the date portion of the resulting DATE object is of the previous day, while the time portion is correct, which means that the DATE object is 24 hours behind.

6. Steps to reproduce:
   Simple test: with DST on, instantiate one OaIdl.DATE(Date javaDate) with a javaDate having the time 12:30am local time and another with 1:30am local time, with the same date, and you'll see that the resulting DATEs have different integralParts.

[dbwiddis]

Java time has no concept of DST, so the first hour of the day ends up being the "last hour" of a 24 hour period with reference to the epoch, as assumed in this calculation:

jna/contrib/platform/src/com/sun/jna/platform/win32/OaIdl.java

Lines 266 to 267 in 0444bf9

	double msSinceOrigin = javaDate.getTime() - DATE_OFFSET;
	double daysAsFract = msSinceOrigin / MICRO_SECONDS_PER_DAY;

However, this may be by design, per the Windows docs for DATE:

The following points should be noted when working with these date and time formats in Automation:

Dates are specified in local time; synchronization must be performed manually when working with dates in different time zones.

The date types do not account for Daylight Savings Time.

One would reason based on that last sentence that it is an error to use a DST-impacted Java Date in this constructor.

[eranl]

Any reason not to use ZonedDateTime for the conversion from UTC to local time, rather than the above calculation?

[dbwiddis]

Any reason not to use ZonedDateTime

It requires JDK 8. We maintain (at least in 5.X series) compatibility with JDK 6.

[dbwiddis]

Apache POI has solved it here using Calendar class.

https://github.com/cuba-platform/apache-poi/blob/667a58fb053aa3b076f8addcdde922cd5e099596/poi/src/java/org/apache/poi/ss/usermodel/DateUtil.java#L103-L132

[eranl]

Thanks for the info. Very interesting.

Here's the latest version: https://svn.apache.org/viewvc/poi/trunk/poi/src/main/java/org/apache/poi/ss/usermodel/DateUtil.java?view=markup

Can I contribute a fix based on this?

[dbwiddis]

Please do.

Also a test case failing in the existing setup and passing with the fix would be helpful.

[matthiasblaesing]

Please note, that your fix must be created by you. You can not copy from Apache POI. JNA is dual licensed ALv2 + LGPL, so pure ALv2 can't be integrated.

[dbwiddis]

Agree that you cannot copy, but there are other factors to consider (POI is based on Jan 1 1900 epoch, DATE is based on Dec 30 1899) so assuming your "based on" means looking at how Calendar was used and doing something similar with the Win32 API base date, I think you'll be fine.

[matthiasblaesing]

Fixed via #1461 (merged via 09d3371). Thank you again.