----------------------------------------------------------------------------------------
It can be done as a last resort.. the main concern is being able to handle times <= 0 in the unix epoch. Windows is silly, and while it uses a signed time_t value (implying it takes negative time values into consideration), its implementation only works with times > 0 in the unix epoch. anything less results in the return of a null pointer or errno, depending on which version of the system library you choose.
On 1/9/06, Mitz Pettel <
[EMAIL PROTECTED]> wrote:
In many territories the rules changed several times over the years (daylight saving time wasn't introduced until the 20th century). In New Zealand, for example, there was no DST between 1946 and 1974.On Jan 9, 2006, at 9:11 PM, Justin Haygood wrote:It would work if the years are equivalent, no?
(the first sunday in april and last sunday in october would be the same guaranteed every 28 years between the years 1601 and 2399)On 1/9/06, Mitz Pettel <[EMAIL PROTECTED] > wrote: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 PettelOn 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 <[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
_______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
