My proposal:
Based on http://www.tondering.dk/claus/cal/node3.html#SECTION00370000000000000000, and some programming knowledge, how about:
- For Windows, check the value of clock. If its 0 or less (it sometimes messes up with 0, sometimes it doesn't...), keep adding 28 years in seconds until its positive (no need to check for above 2038.. Windows uses 64-bit values for time_t if using CRT 8 (aka Visual Studio 2005's CRT) to increase portability between Win32 & Win64.
- Remember the offset in years
- Then, submit that time to the system local/gmtime function (whichever one we choose, aren't we going with the _s versions?)
- Change the returned year using our remembered offset
- Voila, immediate portability.
sizeof(time_t) using MSVC 8 compiler and MSVCRT 8 C library: 8
sizeof(time_t) using MinGW GCC 3.4.2 and MSVCRT 6 C library: 4
On 1/8/06, Justin Haygood
<[EMAIL PROTECTED]> wrote:
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 < [EMAIL PROTECTED]> 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,MaciejOn 1/8/06, Maciej Stachowiak < [EMAIL PROTECTED]> 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,MaciejOn 1/8/06, Maciej Stachowiak < [EMAIL PROTECTED]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
