Kbase P114689: Passing really old dates from AppServer to .Net client causes dates to become corrupted
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
25/02/2010 |
|
Status: Verified
SYMPTOM(s):
Passing really old dates from AppServer to .Net client causes dates to become corrupted
Minimum dates sent from .NET Open Client (1/1/0001) become 13/1/0001 when sent to Progress
it displays 20/12/0007 on the .NET side instead of 01/01/0008.
FACT(s) (Environment):
Problem does not occur with dates after 10/15/1582
OpenEdge 10.x
Windows
CAUSE:
Bug# OE00098615
CAUSE:
The cause of the corrupted dates is due to the fact that Progress (as well as Java) do not represent the days 10/5/1582 through 10/14/1582 because they were vanished from the calendar when the Gregorian Calendar was created. (i.e. In Progress, if you have the date 10/15/1582 and subtract one day, the result is 10/04/1582 - which is the correct behavior). The .Net DateTime object actually represents these dates. (i.e. In .NET if you have the date 10/15/1582 and subtract one day, the result is 10/14/1582 - but this date does not exist in the Gregorian Calendar). To fix this problem, when dealing with pre 10/15/1582 dates, we adjust the date by 10 days when the date value is returned from the AppServer to the .Net client.
However, there still exists another problem in pre 10/15/1582 dates. The problem stems from the fact that Progress represents pre 10/15/1582 dates following the Julian Calendar rules (as does Java) where .Net represents these dates using the Gregorian Calendar rules.
For example, in Progress (and Java), the date 03/01/1500 minus 1 day equals 2/29/1500.
This is because in the Julian Calendar, the year 1500 is designated as a leap year. In .Net the date 03/01/1500 minus 1 day equals 2/28/1500. This is because using Gregorian Calendar rules, the year 1500 is not considered a leap year. Since the Gregorian Calendar does not begin until 10/15/1582, it looks like the .Net DateTime implementation is not correct.
FIX:
Upgrade to 10.2A02 or later.
If upgrading is not an option, modify the application to take the above information into account. The actual code change(s) which need to be made are application specific (depending on the applications needs) but may include passing the dates as character strings which would be converted to dates on the .Net side (if it is critically important that such old dates have the same value on both .Net and the AppServer.