Title says it all, really.
This is mostly date-format-tofte and date-format-xparb.
Created attachment 386889 [details] [diff] [review] try being smart about when DST offset shouldn't matter (beats caching) The attached patch ignores the DST offset, based on some assumptions. Most of them I made while sitting on a plane, so we will have to do some checking and testing for this. - When getting the year, ignore DST offset if we are not within a day of the year transition. Assuming DST offsets are small, they can't affect the year except for those 2 days. Should be pretty safe. - When getting the month, ignore DST offset if we are not talking about the first or last (28+) day of the month. Should be pretty safe too. - When getting the day or weekday, check that we are not near midnight. This assumes that DST offset switching always happens at midnight. It does in every timezone I ever lived in, but we have check for universal truth here. - Based on the last assumption, we can ignore DST offset for minutes and below. This cuts down the DST offset calculation significantly. Potential improvements: - Cache the DST offset-less local time in the Date object (separately from the full local time). That could save another few cycles. Currently we win about 20ms.
Attachment #386847 - Attachment is obsolete: true
So things are a bit more complicated, of course: We have switching at non-hour boundaries too, and the default switching time is 2am, not midnight. Rule Mont 1919 only - Mar 31 2:30 1:00 D The earliest time I have seen in North America is: Rule Winn 1945 only - Aug 14 23:00u 1:00 P # Peace The latest: -6:00 - CST 2001 Apr 1 3:00 Other continents switch even later: Rule ChileAQ 1991 1997 - Oct Sun>=9 4:00u 1:00 S And also earlier: Rule Russia 1918 only - May 31 22:00 2:00 MDST # Moscow Double Summer Time And if this is correct, that really screws us over: Rule Greece 1979 only - Apr 1 9:00 1:00 S We can still save the day by special-casing the heuristics a bit. I will write a zoneinfo parser to generate the necessary invariants next time I am flying across the Atlantic :)
dbaron is a time nerd, cc'ing him for advice. /be
How about this for a wild suggestion. Precompute the start time and end time for DST in each of the years within the operating system trust region (currently 1970-2038*). This could be done once in js_InitDateClass(). Then DaylightSavingTA() doesn't need to call PRMJ_DSTOffset at all -- it just figures out which year to look at and checks if t >= DST_start[year-1970] || t < DST_end[year-1970]. Doing the precomputation may be a pain; it might have to be bisection based on calling PRMJ_DSTOffset which is a tad bit expensive in startup time. But if it was preseeded with a table of guesses as to the right DST times and just has to call the operating system to check if its pre-coded guesses are correct, the normal case (guesses are correct) is something like just 4 calls to PRMJ_DSTOffset for each year being tabulated -- check the guessed start and end dates +- 1 millisecond to see if this is the correct discontinuity points. Or maybe there is an interface already to find when DST starts and ends in a given year? * note this code has an explicit year 2038 bug in its working around potential OS year 2038 problems -- it never trusts the OS regarding DST for years 2038 or later, instead asking for DST computations from a similar date back in the 20th century. But DST rules change periodically at government whim, so the old dates aren't really necessarily equivalent. *
Created attachment 461302 [details] [diff] [review] dst offset speedup This patch speeds up the computation of DST offsets, and modifies the DST cache to handle the pattern seen in date-format-tofte, alternating between two sets of dates several years apart. Saves 4ms in JM on SS for me.
Updated patch at bug 578259. What's the status of this bug, and how should it interact with bug 578259?
Using approach in bug 578259
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.