michael@0: /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*- michael@0: * vim: set ts=8 sts=4 et sw=4 tw=99: michael@0: * This Source Code Form is subject to the terms of the Mozilla Public michael@0: * License, v. 2.0. If a copy of the MPL was not distributed with this michael@0: * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ michael@0: michael@0: #ifndef vm_DateTime_h michael@0: #define vm_DateTime_h michael@0: michael@0: #include "mozilla/FloatingPoint.h" michael@0: #include "mozilla/MathAlgorithms.h" michael@0: michael@0: #include michael@0: michael@0: #include "js/Value.h" michael@0: #include "vm/NumericConversions.h" michael@0: michael@0: namespace js { michael@0: michael@0: /* Constants defined by ES5 15.9.1.10. */ michael@0: const double HoursPerDay = 24; michael@0: const double MinutesPerHour = 60; michael@0: const double SecondsPerMinute = 60; michael@0: const double msPerSecond = 1000; michael@0: const double msPerMinute = msPerSecond * SecondsPerMinute; michael@0: const double msPerHour = msPerMinute * MinutesPerHour; michael@0: michael@0: /* ES5 15.9.1.2. */ michael@0: const double msPerDay = msPerHour * HoursPerDay; michael@0: michael@0: /* michael@0: * Additional quantities not mentioned in the spec. Be careful using these! michael@0: * They aren't doubles (and aren't defined in terms of all the other constants michael@0: * so that they can be used in constexpr scenarios; if you need constants that michael@0: * trigger floating point semantics, you'll have to manually cast to get it. michael@0: */ michael@0: const unsigned SecondsPerHour = 60 * 60; michael@0: const unsigned SecondsPerDay = SecondsPerHour * 24; michael@0: michael@0: const double StartOfTime = -8.64e15; michael@0: const double EndOfTime = 8.64e15; michael@0: const double MaxTimeMagnitude = 8.64e15; michael@0: michael@0: /* ES5 15.9.1.14. */ michael@0: inline double michael@0: TimeClip(double time) michael@0: { michael@0: /* Steps 1-2. */ michael@0: if (!mozilla::IsFinite(time) || mozilla::Abs(time) > MaxTimeMagnitude) michael@0: return JS::GenericNaN(); michael@0: michael@0: /* Step 3. */ michael@0: return ToInteger(time + (+0.0)); michael@0: } michael@0: michael@0: /* michael@0: * Stores date/time information, particularly concerning the current local michael@0: * time zone, and implements a small cache for daylight saving time offset michael@0: * computation. michael@0: * michael@0: * The basic idea is premised upon this fact: the DST offset never changes more michael@0: * than once in any thirty-day period. If we know the offset at t_0 is o_0, michael@0: * the offset at [t_1, t_2] is also o_0, where t_1 + 3_0 days == t_2, michael@0: * t_1 <= t_0, and t0 <= t2. (In other words, t_0 is always somewhere within a michael@0: * thirty-day range where the DST offset is constant: DST changes never occur michael@0: * more than once in any thirty-day period.) Therefore, if we intelligently michael@0: * retain knowledge of the offset for a range of dates (which may vary over michael@0: * time), and if requests are usually for dates within that range, we can often michael@0: * provide a response without repeated offset calculation. michael@0: * michael@0: * Our caching strategy is as follows: on the first request at date t_0 compute michael@0: * the requested offset o_0. Save { start: t_0, end: t_0, offset: o_0 } as the michael@0: * cache's state. Subsequent requests within that range are straightforwardly michael@0: * handled. If a request for t_i is far outside the range (more than thirty michael@0: * days), compute o_i = dstOffset(t_i) and save { start: t_i, end: t_i, michael@0: * offset: t_i }. Otherwise attempt to *overextend* the range to either michael@0: * [start - 30d, end] or [start, end + 30d] as appropriate to encompass michael@0: * t_i. If the offset o_i30 is the same as the cached offset, extend the michael@0: * range. Otherwise the over-guess crossed a DST change -- compute michael@0: * o_i = dstOffset(t_i) and either extend the original range (if o_i == offset) michael@0: * or start a new one beneath/above the current one with o_i30 as the offset. michael@0: * michael@0: * This cache strategy results in 0 to 2 DST offset computations. The naive michael@0: * always-compute strategy is 1 computation, and since cache maintenance is a michael@0: * handful of integer arithmetic instructions the speed difference between michael@0: * always-1 and 1-with-cache is negligible. Caching loses if two computations michael@0: * happen: when the date is within 30 days of the cached range and when that michael@0: * 30-day range crosses a DST change. This is relatively uncommon. Further, michael@0: * instances of such are often dominated by in-range hits, so caching is an michael@0: * overall slight win. michael@0: * michael@0: * Why 30 days? For correctness the duration must be smaller than any possible michael@0: * duration between DST changes. Past that, note that 1) a large duration michael@0: * increases the likelihood of crossing a DST change while reducing the number michael@0: * of cache misses, and 2) a small duration decreases the size of the cached michael@0: * range while producing more misses. Using a month as the interval change is michael@0: * a balance between these two that tries to optimize for the calendar month at michael@0: * a time that a site might display. (One could imagine an adaptive duration michael@0: * that accommodates near-DST-change dates better; we don't believe the michael@0: * potential win from better caching offsets the loss from extra complexity.) michael@0: */ michael@0: class DateTimeInfo michael@0: { michael@0: public: michael@0: DateTimeInfo(); michael@0: michael@0: /* michael@0: * Get the DST offset in milliseconds at a UTC time. This is usually michael@0: * either 0 or |msPerSecond * SecondsPerHour|, but at least one exotic time michael@0: * zone (Lord Howe Island, Australia) has a fractional-hour offset, just to michael@0: * keep things interesting. michael@0: */ michael@0: int64_t getDSTOffsetMilliseconds(int64_t utcMilliseconds); michael@0: michael@0: void updateTimeZoneAdjustment(); michael@0: michael@0: /* ES5 15.9.1.7. */ michael@0: double localTZA() { return localTZA_; } michael@0: michael@0: private: michael@0: /* michael@0: * The current local time zone adjustment, cached because retrieving this michael@0: * dynamically is Slow, and a certain venerable benchmark which shall not michael@0: * be named depends on it being fast. michael@0: * michael@0: * SpiderMonkey occasionally and arbitrarily updates this value from the michael@0: * system time zone to attempt to keep this reasonably up-to-date. If michael@0: * temporary inaccuracy can't be tolerated, JSAPI clients may call michael@0: * JS_ClearDateCaches to forcibly sync this with the system time zone. michael@0: */ michael@0: double localTZA_; michael@0: michael@0: /* michael@0: * Compute the DST offset at the given UTC time in seconds from the epoch. michael@0: * (getDSTOffsetMilliseconds attempts to return a cached value, but in case michael@0: * of a cache miss it calls this method. The cache is represented through michael@0: * the offset* and *{Start,End}Seconds fields below.) michael@0: */ michael@0: int64_t computeDSTOffsetMilliseconds(int64_t utcSeconds); michael@0: michael@0: int64_t offsetMilliseconds; michael@0: int64_t rangeStartSeconds, rangeEndSeconds; // UTC-based michael@0: michael@0: int64_t oldOffsetMilliseconds; michael@0: int64_t oldRangeStartSeconds, oldRangeEndSeconds; // UTC-based michael@0: michael@0: /* michael@0: * Cached offset in seconds from the current UTC time to the current michael@0: * local standard time (i.e. not including any offset due to DST). michael@0: */ michael@0: int32_t utcToLocalStandardOffsetSeconds; michael@0: michael@0: static const int64_t MaxUnixTimeT = 2145859200; /* time_t 12/31/2037 */ michael@0: michael@0: static const int64_t RangeExpansionAmount = 30 * SecondsPerDay; michael@0: michael@0: void sanityCheck(); michael@0: }; michael@0: michael@0: } /* namespace js */ michael@0: michael@0: #endif /* vm_DateTime_h */