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

[Mitz Pettel]

I didn't follow the discussion very closely, hence I apologize if  
this irrelevant here, but the "offset years" technique doesn't play  
well with daylight saving time, so I think you should only apply it  
as a last resort (see e.g. <http://bugzilla.opendarwin.org/ 
show_bug.cgi?id=5514>).

-- Mitz Pettel

On Jan 9, 2006, at 8:54 PM, Justin Haygood wrote:

> 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
>>>
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060109/cb5a2fdc/attachment.html