javadelphidatecalendartdatetime

Delphi tdatetime to Java Date/Calender


I have a question for you Delphi-cracks out there.

My Java application is communcating with a Delphi Application. The Delphi Application shows some date values within its UI which should be transfered into the Java application via file.

But instead of a UTC or whatever time-string the delphi application exports some floating point numbers which I expect to be just the internal tdatetime-values of the dates.

The following illustrates this using MM/dd/YYYY format:

I'm aware, that the Delphi tdatetime value uses 30/12/1899 as a reference.

Therefor I expected the following code snipet to do the trick:

Calendar c = Calendar.getInstance();

c.set(1899, 11, 30, 0, 0);// init delphi version of start of time

c.add(Calendar.DATE, <FloatingPoint>); // add in the days
// minutes not required as all values end with .00

SimpleDateFormat sdf = new SimpleDateFormat();
System.out.println(sdf.format(c.getTime())); // voila

Yet to my suprise this is not correct

So what's wrong my code snippet and the conversion?

Actually I don't have the application itself, just screenshots of the UI and the exported files. Therefor there is the slight chance, that the screenshot and the export might itself be not entirely correct.

This would also explain, why

Any other explanations? I thought it might be related to different treatments of leap years within Java and Delphie, yet I have not been able to figure this out.

Same problem appears when using a Date and doing some ms-additions instead. The converted dates don't always match the expected values in the UI.

Anyone did conversions of delphi tdatetime to java with a similar snipet as the above and did not encounter any glitches?


Solution

  • program Project1;
    
    {$APPTYPE CONSOLE}
    
    uses
      DateUtils;
    
    var
      t : TDateTime;
      d : double;
    begin
      t := EncodeDateTime(2017,05,31,0,0,0,0);
      d := t;
      WriteLn(d);
      ReadLn;
    end.
    

    This outputs value 42886, not 42887 as suggested by your source data. I suspect your screenshots and text files are not entirely accurate.

    For datetime values with no fractional component your approach is correct.