On Wed, 2007-09-05 at 18:07 +0200, Alexandre Julliard wrote: > Bill Medland <[EMAIL PROTECTED]> writes: > > > On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote: > >> Bill Medland ([EMAIL PROTECTED]) > >> 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
