1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/js/src/vm/DateTime.h Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,162 @@
1.4 +/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
1.5 + * vim: set ts=8 sts=4 et sw=4 tw=99:
1.6 + * This Source Code Form is subject to the terms of the Mozilla Public
1.7 + * License, v. 2.0. If a copy of the MPL was not distributed with this
1.8 + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
1.9 +
1.10 +#ifndef vm_DateTime_h
1.11 +#define vm_DateTime_h
1.12 +
1.13 +#include "mozilla/FloatingPoint.h"
1.14 +#include "mozilla/MathAlgorithms.h"
1.15 +
1.16 +#include <stdint.h>
1.17 +
1.18 +#include "js/Value.h"
1.19 +#include "vm/NumericConversions.h"
1.20 +
1.21 +namespace js {
1.22 +
1.23 +/* Constants defined by ES5 15.9.1.10. */
1.24 +const double HoursPerDay = 24;
1.25 +const double MinutesPerHour = 60;
1.26 +const double SecondsPerMinute = 60;
1.27 +const double msPerSecond = 1000;
1.28 +const double msPerMinute = msPerSecond * SecondsPerMinute;
1.29 +const double msPerHour = msPerMinute * MinutesPerHour;
1.30 +
1.31 +/* ES5 15.9.1.2. */
1.32 +const double msPerDay = msPerHour * HoursPerDay;
1.33 +
1.34 +/*
1.35 + * Additional quantities not mentioned in the spec. Be careful using these!
1.36 + * They aren't doubles (and aren't defined in terms of all the other constants
1.37 + * so that they can be used in constexpr scenarios; if you need constants that
1.38 + * trigger floating point semantics, you'll have to manually cast to get it.
1.39 + */
1.40 +const unsigned SecondsPerHour = 60 * 60;
1.41 +const unsigned SecondsPerDay = SecondsPerHour * 24;
1.42 +
1.43 +const double StartOfTime = -8.64e15;
1.44 +const double EndOfTime = 8.64e15;
1.45 +const double MaxTimeMagnitude = 8.64e15;
1.46 +
1.47 +/* ES5 15.9.1.14. */
1.48 +inline double
1.49 +TimeClip(double time)
1.50 +{
1.51 + /* Steps 1-2. */
1.52 + if (!mozilla::IsFinite(time) || mozilla::Abs(time) > MaxTimeMagnitude)
1.53 + return JS::GenericNaN();
1.54 +
1.55 + /* Step 3. */
1.56 + return ToInteger(time + (+0.0));
1.57 +}
1.58 +
1.59 +/*
1.60 + * Stores date/time information, particularly concerning the current local
1.61 + * time zone, and implements a small cache for daylight saving time offset
1.62 + * computation.
1.63 + *
1.64 + * The basic idea is premised upon this fact: the DST offset never changes more
1.65 + * than once in any thirty-day period. If we know the offset at t_0 is o_0,
1.66 + * the offset at [t_1, t_2] is also o_0, where t_1 + 3_0 days == t_2,
1.67 + * t_1 <= t_0, and t0 <= t2. (In other words, t_0 is always somewhere within a
1.68 + * thirty-day range where the DST offset is constant: DST changes never occur
1.69 + * more than once in any thirty-day period.) Therefore, if we intelligently
1.70 + * retain knowledge of the offset for a range of dates (which may vary over
1.71 + * time), and if requests are usually for dates within that range, we can often
1.72 + * provide a response without repeated offset calculation.
1.73 + *
1.74 + * Our caching strategy is as follows: on the first request at date t_0 compute
1.75 + * the requested offset o_0. Save { start: t_0, end: t_0, offset: o_0 } as the
1.76 + * cache's state. Subsequent requests within that range are straightforwardly
1.77 + * handled. If a request for t_i is far outside the range (more than thirty
1.78 + * days), compute o_i = dstOffset(t_i) and save { start: t_i, end: t_i,
1.79 + * offset: t_i }. Otherwise attempt to *overextend* the range to either
1.80 + * [start - 30d, end] or [start, end + 30d] as appropriate to encompass
1.81 + * t_i. If the offset o_i30 is the same as the cached offset, extend the
1.82 + * range. Otherwise the over-guess crossed a DST change -- compute
1.83 + * o_i = dstOffset(t_i) and either extend the original range (if o_i == offset)
1.84 + * or start a new one beneath/above the current one with o_i30 as the offset.
1.85 + *
1.86 + * This cache strategy results in 0 to 2 DST offset computations. The naive
1.87 + * always-compute strategy is 1 computation, and since cache maintenance is a
1.88 + * handful of integer arithmetic instructions the speed difference between
1.89 + * always-1 and 1-with-cache is negligible. Caching loses if two computations
1.90 + * happen: when the date is within 30 days of the cached range and when that
1.91 + * 30-day range crosses a DST change. This is relatively uncommon. Further,
1.92 + * instances of such are often dominated by in-range hits, so caching is an
1.93 + * overall slight win.
1.94 + *
1.95 + * Why 30 days? For correctness the duration must be smaller than any possible
1.96 + * duration between DST changes. Past that, note that 1) a large duration
1.97 + * increases the likelihood of crossing a DST change while reducing the number
1.98 + * of cache misses, and 2) a small duration decreases the size of the cached
1.99 + * range while producing more misses. Using a month as the interval change is
1.100 + * a balance between these two that tries to optimize for the calendar month at
1.101 + * a time that a site might display. (One could imagine an adaptive duration
1.102 + * that accommodates near-DST-change dates better; we don't believe the
1.103 + * potential win from better caching offsets the loss from extra complexity.)
1.104 + */
1.105 +class DateTimeInfo
1.106 +{
1.107 + public:
1.108 + DateTimeInfo();
1.109 +
1.110 + /*
1.111 + * Get the DST offset in milliseconds at a UTC time. This is usually
1.112 + * either 0 or |msPerSecond * SecondsPerHour|, but at least one exotic time
1.113 + * zone (Lord Howe Island, Australia) has a fractional-hour offset, just to
1.114 + * keep things interesting.
1.115 + */
1.116 + int64_t getDSTOffsetMilliseconds(int64_t utcMilliseconds);
1.117 +
1.118 + void updateTimeZoneAdjustment();
1.119 +
1.120 + /* ES5 15.9.1.7. */
1.121 + double localTZA() { return localTZA_; }
1.122 +
1.123 + private:
1.124 + /*
1.125 + * The current local time zone adjustment, cached because retrieving this
1.126 + * dynamically is Slow, and a certain venerable benchmark which shall not
1.127 + * be named depends on it being fast.
1.128 + *
1.129 + * SpiderMonkey occasionally and arbitrarily updates this value from the
1.130 + * system time zone to attempt to keep this reasonably up-to-date. If
1.131 + * temporary inaccuracy can't be tolerated, JSAPI clients may call
1.132 + * JS_ClearDateCaches to forcibly sync this with the system time zone.
1.133 + */
1.134 + double localTZA_;
1.135 +
1.136 + /*
1.137 + * Compute the DST offset at the given UTC time in seconds from the epoch.
1.138 + * (getDSTOffsetMilliseconds attempts to return a cached value, but in case
1.139 + * of a cache miss it calls this method. The cache is represented through
1.140 + * the offset* and *{Start,End}Seconds fields below.)
1.141 + */
1.142 + int64_t computeDSTOffsetMilliseconds(int64_t utcSeconds);
1.143 +
1.144 + int64_t offsetMilliseconds;
1.145 + int64_t rangeStartSeconds, rangeEndSeconds; // UTC-based
1.146 +
1.147 + int64_t oldOffsetMilliseconds;
1.148 + int64_t oldRangeStartSeconds, oldRangeEndSeconds; // UTC-based
1.149 +
1.150 + /*
1.151 + * Cached offset in seconds from the current UTC time to the current
1.152 + * local standard time (i.e. not including any offset due to DST).
1.153 + */
1.154 + int32_t utcToLocalStandardOffsetSeconds;
1.155 +
1.156 + static const int64_t MaxUnixTimeT = 2145859200; /* time_t 12/31/2037 */
1.157 +
1.158 + static const int64_t RangeExpansionAmount = 30 * SecondsPerDay;
1.159 +
1.160 + void sanityCheck();
1.161 +};
1.162 +
1.163 +} /* namespace js */
1.164 +
1.165 +#endif /* vm_DateTime_h */
