I don't think the date-parse benchmark is a good reason to change the DST
calculation this drastically. It is an artificial benchmark, not used in
published results. The principle of relying on the OS to tell us what is
in DST
and what is not is important, I think, and there are dangers to abandoning
it.
Do other, important benchmarks, also spend most of their time in DST?
The original problem was to find a way to make V8 notice changes in the time
zone. We can do this on context creation, on a timer, or some other way.
Right
now, I think we do it on missing the DST cache, and also on fetching the
string
for the time zone.
http://codereview.chromium.org/1758013/diff/4001/5003
File src/platform-posix.cc (right):
http://codereview.chromium.org/1758013/diff/4001/5003#newcode111
src/platform-posix.cc:111: time_t tv = static_cast<time_t>(time /
msPerSecond);
Eliminating the floor call changes the answer if time is negative. Are
we not calling this function with negative values? If so, comment.
http://codereview.chromium.org/1758013/diff/4001/5006
File src/runtime.cc (right):
http://codereview.chromium.org/1758013/diff/4001/5006#newcode7280
src/runtime.cc:7280: static int EquivalentTime(double t) {
This doesn't work. There are also special rules for years divisible by
1000, and there is the calendar shift to the Gregorian calendar. Also,
Windows now can return different DST values for different equivalent
years in the range 1970 - present, and for compatibility, we report
those different DST values. Only for years outside the range
1970-2037(?) do we use the equivalent year.
http://codereview.chromium.org/1758013/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
