I was thinking, isn't there equivalent years like every 7 (or whatever it is) years or so? For negative year values, we simply could adjust it to an equivalent year, remember the year offset, and readjust to the correct year after letting localtime/gmtime do its magic? On 1/8/06, Maciej Stachowiak <mjs@apple.com> wrote:
On Jan 7, 2006, at 9:23 PM, Justin Haygood wrote:
Try telling that to date_object.cpp. It does the Windows equivalent of dumping core anytime a negative date value is used or a new Date object is created.
Sounds bad. Do you have any ideas how that could be fixed? I'll have a Windows laptop soon so I may be able to test things myself.
Regards, Maciej
On 1/8/06, Maciej Stachowiak <mjs@apple.com> wrote:
On Jan 7, 2006, at 9:13 PM, Justin Haygood wrote:
Either one is an issue.
Windows does do one thing better: it supports dates beyond the 2038 even in vanilla localtime/gmtime.. it uses 64-bit values since the epoch by default in CRT 8.
Actually I'm not sure we'd use negative time values with the latest code. Is there a case where this comes up? I think dates are converted into a consistent narrow range currently.
Regards, Maciej
On 1/8/06, Maciej Stachowiak <mjs@apple.com> wrote:
On Jan 7, 2006, at 8:57 PM, Justin Haygood wrote:
The only problem with localtime_r and gmtime_r, when implemented in any matter that uses the CRT (We target CRT 8.. its the most current and really the only viable CRT) is that they don't work with negative time values, returning a NULL pointer.
Since KJS doesn't realize that a NULL pointer can be given to it, it crashes miserably once it attempts to use this pointer.
Are the _s variants safe for use with negative time values? How about vanilla localtime()? It seems like this is an issue regardless.
Cheers, Maciej