Someone should check my math, but the number is from:
60 secs in 1 minute *
60 mins in 1 hour *
24 hours in 1 day *
365 days in 1 year
Then to adjust for leap years:
7 leap years in 28 years (7*4 = 28...)
60 secs in 1 minute *
60 mins in 1 hour *
24 hours in 1 day *
7 leap days in 7 leap years
Summing gives the answer I gave above. Someone who isn't sick and actually feels like checking a calendar to make sure there are 7 leap years in 28 years should check my math though...
On 1/9/06, Justin Haygood <[EMAIL PROTECTED]> wrote:
(Sorry for the subject change -- updating to make it more accurate -- threaded mail readers should still keep it in the thread)
My proposal:
Based on http://www.tondering.dk/claus/cal/node3.html#SECTION00370000000000000000, and some programming knowledge, how about:We might want to do this globally instead of just for one platform. We might also do this for years above 2038 as well if time_t is 32-bit instead of 64-bit on a given platform.
- 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: 4On 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
