Localized date not properly localized when prior to 1900
0
Hello, We have a very inconvenient issue with localized dates, when they are prior to 1900. Here is the context : - We get data from an Excel, from which one column is a date - We parse this date column in order to force the localization in the user's timezone (using the Java Action `ParseDateTimeWithTimezone` from CommunityCommons) to be consistent with dates input from users (this step was necessary, otherwise a user input date was not matching the excel data, despite being the same dates) - We then display this date in a page This works properly with dates from 1900-01-01, the dates are correctly converted in the database in the expected UTC format, and the dates are properly displayed in the user interface, with the correct localization. But we get an inconsistency, when using dates prior to 1900. Here is an example with 1850-01-01, that is displayed like so in the pages : 1849-12-31 23:34:08:0000 (I added the timestamp, to better understand what is going on, but what we saw in the interface at first was 1849-12-31). However, the value in the databse is correct : 1849-12-31 23:00:00.000. Since it is stored in the UTC format, and the timezone being in UTC+1, we get indeed 1850-01-01 00:00:00:0000. Moreover, I entered the same date (1850-01-01) in the user interface and it is stored like this in DB : 1849-12-31 23:25:52.000 (while I would expect 1849-12-31 23:00:00:0000, to match the localization in UTC+1). We can notice, though, that there is still some consistency, since the shift is indeed of 34 minutes and 8 seconds in both cases (instead of 1 hour, as we would expect in UTC+1). But the shift is not the same if I input another year. Here is how 1856-01-17 is stored in DB : 1856-01-16 23:30:14.000 (so a shift of 29 minutes and 46 seconds, still not 1 hour). So there seem to be an issue in the process of storing localized dates, when they are prior to 1900. Unless there was a weird daylight saving rule in the 1800s that I am not aware of and that is applied here. So, if it is not considered a bug in the Mendix Runtime, we would really appreciate some help on how to address this issue. And removing the localization is not an option, we need to keep those date attributes to be localized. Thanks in advance for your help.