[webkit-dev] Re: KJS Date Object : thread safetyness / portability concerns

[Justin Haygood]

By my calculation, this would mean adding or subtracting 32140800 seconds
until its within the portable range.

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 <jhaygood at spsu.edu> 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:
>
>
>    - 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.
>
> 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.
>
> 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 <jhaygood at spsu.edu> 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 < mjs at 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 at 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 at 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060109/07a80d24/attachment.html