The Tor Browser / file comparison
comparison: js/src/vm/DateTime.h
js/src/vm/DateTime.h
- branch
- TOR_BUG_3246
- changeset 7
- 129ffea94266
equal
deleted
inserted
replaced
| -1:000000000000 | 0:e40ca195e6b9 |
|---|---|
| 1 /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*- | |
| 2 * vim: set ts=8 sts=4 et sw=4 tw=99: | |
| 3 * This Source Code Form is subject to the terms of the Mozilla Public | |
| 4 * License, v. 2.0. If a copy of the MPL was not distributed with this | |
| 5 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ | |
| 6 | |
| 7 #ifndef vm_DateTime_h | |
| 8 #define vm_DateTime_h | |
| 9 | |
| 10 #include "mozilla/FloatingPoint.h" | |
| 11 #include "mozilla/MathAlgorithms.h" | |
| 12 | |
| 13 #include <stdint.h> | |
| 14 | |
| 15 #include "js/Value.h" | |
| 16 #include "vm/NumericConversions.h" | |
| 17 | |
| 18 namespace js { | |
| 19 | |
| 20 /* Constants defined by ES5 15.9.1.10. */ | |
| 21 const double HoursPerDay = 24; | |
| 22 const double MinutesPerHour = 60; | |
| 23 const double SecondsPerMinute = 60; | |
| 24 const double msPerSecond = 1000; | |
| 25 const double msPerMinute = msPerSecond * SecondsPerMinute; | |
| 26 const double msPerHour = msPerMinute * MinutesPerHour; | |
| 27 | |
| 28 /* ES5 15.9.1.2. */ | |
| 29 const double msPerDay = msPerHour * HoursPerDay; | |
| 30 | |
| 31 /* | |
| 32 * Additional quantities not mentioned in the spec. Be careful using these! | |
| 33 * They aren't doubles (and aren't defined in terms of all the other constants | |
| 34 * so that they can be used in constexpr scenarios; if you need constants that | |
| 35 * trigger floating point semantics, you'll have to manually cast to get it. | |
| 36 */ | |
| 37 const unsigned SecondsPerHour = 60 * 60; | |
| 38 const unsigned SecondsPerDay = SecondsPerHour * 24; | |
| 39 | |
| 40 const double StartOfTime = -8.64e15; | |
| 41 const double EndOfTime = 8.64e15; | |
| 42 const double MaxTimeMagnitude = 8.64e15; | |
| 43 | |
| 44 /* ES5 15.9.1.14. */ | |
| 45 inline double | |
| 46 TimeClip(double time) | |
| 47 { | |
| 48 /* Steps 1-2. */ | |
| 49 if (!mozilla::IsFinite(time) || mozilla::Abs(time) > MaxTimeMagnitude) | |
| 50 return JS::GenericNaN(); | |
| 51 | |
| 52 /* Step 3. */ | |
| 53 return ToInteger(time + (+0.0)); | |
| 54 } | |
| 55 | |
| 56 /* | |
| 57 * Stores date/time information, particularly concerning the current local | |
| 58 * time zone, and implements a small cache for daylight saving time offset | |
| 59 * computation. | |
| 60 * | |
| 61 * The basic idea is premised upon this fact: the DST offset never changes more | |
| 62 * than once in any thirty-day period. If we know the offset at t_0 is o_0, | |
| 63 * the offset at [t_1, t_2] is also o_0, where t_1 + 3_0 days == t_2, | |
| 64 * t_1 <= t_0, and t0 <= t2. (In other words, t_0 is always somewhere within a | |
| 65 * thirty-day range where the DST offset is constant: DST changes never occur | |
| 66 * more than once in any thirty-day period.) Therefore, if we intelligently | |
| 67 * retain knowledge of the offset for a range of dates (which may vary over | |
| 68 * time), and if requests are usually for dates within that range, we can often | |
| 69 * provide a response without repeated offset calculation. | |
| 70 * | |
| 71 * Our caching strategy is as follows: on the first request at date t_0 compute | |
| 72 * the requested offset o_0. Save { start: t_0, end: t_0, offset: o_0 } as the | |
| 73 * cache's state. Subsequent requests within that range are straightforwardly | |
| 74 * handled. If a request for t_i is far outside the range (more than thirty | |
| 75 * days), compute o_i = dstOffset(t_i) and save { start: t_i, end: t_i, | |
| 76 * offset: t_i }. Otherwise attempt to *overextend* the range to either | |
| 77 * [start - 30d, end] or [start, end + 30d] as appropriate to encompass | |
| 78 * t_i. If the offset o_i30 is the same as the cached offset, extend the | |
| 79 * range. Otherwise the over-guess crossed a DST change -- compute | |
| 80 * o_i = dstOffset(t_i) and either extend the original range (if o_i == offset) | |
| 81 * or start a new one beneath/above the current one with o_i30 as the offset. | |
| 82 * | |
| 83 * This cache strategy results in 0 to 2 DST offset computations. The naive | |
| 84 * always-compute strategy is 1 computation, and since cache maintenance is a | |
| 85 * handful of integer arithmetic instructions the speed difference between | |
| 86 * always-1 and 1-with-cache is negligible. Caching loses if two computations | |
| 87 * happen: when the date is within 30 days of the cached range and when that | |
| 88 * 30-day range crosses a DST change. This is relatively uncommon. Further, | |
| 89 * instances of such are often dominated by in-range hits, so caching is an | |
| 90 * overall slight win. | |
| 91 * | |
| 92 * Why 30 days? For correctness the duration must be smaller than any possible | |
| 93 * duration between DST changes. Past that, note that 1) a large duration | |
| 94 * increases the likelihood of crossing a DST change while reducing the number | |
| 95 * of cache misses, and 2) a small duration decreases the size of the cached | |
| 96 * range while producing more misses. Using a month as the interval change is | |
| 97 * a balance between these two that tries to optimize for the calendar month at | |
| 98 * a time that a site might display. (One could imagine an adaptive duration | |
| 99 * that accommodates near-DST-change dates better; we don't believe the | |
| 100 * potential win from better caching offsets the loss from extra complexity.) | |
| 101 */ | |
| 102 class DateTimeInfo | |
| 103 { | |
| 104 public: | |
| 105 DateTimeInfo(); | |
| 106 | |
| 107 /* | |
| 108 * Get the DST offset in milliseconds at a UTC time. This is usually | |
| 109 * either 0 or |msPerSecond * SecondsPerHour|, but at least one exotic time | |
| 110 * zone (Lord Howe Island, Australia) has a fractional-hour offset, just to | |
| 111 * keep things interesting. | |
| 112 */ | |
| 113 int64_t getDSTOffsetMilliseconds(int64_t utcMilliseconds); | |
| 114 | |
| 115 void updateTimeZoneAdjustment(); | |
| 116 | |
| 117 /* ES5 15.9.1.7. */ | |
| 118 double localTZA() { return localTZA_; } | |
| 119 | |
| 120 private: | |
| 121 /* | |
| 122 * The current local time zone adjustment, cached because retrieving this | |
| 123 * dynamically is Slow, and a certain venerable benchmark which shall not | |
| 124 * be named depends on it being fast. | |
| 125 * | |
| 126 * SpiderMonkey occasionally and arbitrarily updates this value from the | |
| 127 * system time zone to attempt to keep this reasonably up-to-date. If | |
| 128 * temporary inaccuracy can't be tolerated, JSAPI clients may call | |
| 129 * JS_ClearDateCaches to forcibly sync this with the system time zone. | |
| 130 */ | |
| 131 double localTZA_; | |
| 132 | |
| 133 /* | |
| 134 * Compute the DST offset at the given UTC time in seconds from the epoch. | |
| 135 * (getDSTOffsetMilliseconds attempts to return a cached value, but in case | |
| 136 * of a cache miss it calls this method. The cache is represented through | |
| 137 * the offset* and *{Start,End}Seconds fields below.) | |
| 138 */ | |
| 139 int64_t computeDSTOffsetMilliseconds(int64_t utcSeconds); | |
| 140 | |
| 141 int64_t offsetMilliseconds; | |
| 142 int64_t rangeStartSeconds, rangeEndSeconds; // UTC-based | |
| 143 | |
| 144 int64_t oldOffsetMilliseconds; | |
| 145 int64_t oldRangeStartSeconds, oldRangeEndSeconds; // UTC-based | |
| 146 | |
| 147 /* | |
| 148 * Cached offset in seconds from the current UTC time to the current | |
| 149 * local standard time (i.e. not including any offset due to DST). | |
| 150 */ | |
| 151 int32_t utcToLocalStandardOffsetSeconds; | |
| 152 | |
| 153 static const int64_t MaxUnixTimeT = 2145859200; /* time_t 12/31/2037 */ | |
| 154 | |
| 155 static const int64_t RangeExpansionAmount = 30 * SecondsPerDay; | |
| 156 | |
| 157 void sanityCheck(); | |
| 158 }; | |
| 159 | |
| 160 } /* namespace js */ | |
| 161 | |
| 162 #endif /* vm_DateTime_h */ |
