Correct VarBstrFromDate for dates between DATE_MIN and 1601

[Bill Medland]

On Wed, 2007-09-05 at 18:07 +0200, Alexandre Julliard wrote:
> Bill Medland <billmedland at shaw.ca> writes:
> 
> > On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote:
> >> Bill Medland (billmedland at shaw.ca)
> >> Correct VarBstrFromDate for dates between DATE_MIN and 1601
> >> 
> >
> > Has this been rejected out of hand or is it still being considered?
> 
> Rejected, adding a secret wine-only flag to GetDateFormat is ugly. You
> need to find another way to do that.
> 
I thought you might say that.
Can you please look at the following and give me hints as to what you
are prepared to accept:

If I redo it like this will you accept it?
+ Add the secret wine-only flag privately within lcformat.c (as has
already been done with the DATE_DATEVARSONLY and TIME_TIMEVARSONLY)
+ NLS_GetDateTimeFormatW as in the submitted patch
+ Add a wine-only function (e.g. wineGetDateTimeFormatFullRange) that
calls NLS_GetDateTimeFormatW with the now-private wine-only flag

If not, how about this?
+ Add an argument to NLS_GetDateTimeFormatW for the wine-specific flags
(to avoid potential conflict with true flags, which we already have)
+ Add a wine-only function (e.g. wineGetDateTimeFormatFullRange) that
calls NLS_GetDateTimeFormatW with the now-private wine-only flag

Presumably this is not an option (I hate even to mention it but you are
not leaving many options)
+ Copy the existing NLS_GetDateTimeFormatW up into oleaut32 and modify
the copy to remove the restriction on dates.




The fundamental problem is:
+ The ability to format dates and times is currently down in the
kernel32 and ntdll
+ That code is structured around dates from 1601 upwards
+ oleaut32 handles dates from 1 January 100 upwards (up to a maximum)

The only solutions I see are:

+ Leave it as it is (and hard luck to anyone who uses dates in the range
1/1/100 to 1/1/1601)
+ Add support down in kernel32/ntdll to format dates in that range
+ Duplicate and morph sufficient date formatting up in oleaut32
specifically for this case
+ Add some very magic code up in oleaut32 that does some really weird
stuff like mapping the range 1/1/100 to 31/12/1600 into a valid range,
calling the kernel32 functions and then patching up the result (e.g.
figuring out where the year is in the string and changing it back).

Which would you accept?

Respectfully 

Bill Medland