2012-03-09 12:07:29 +00:00
|
|
|
// Copyright 2012 the V8 project authors. All rights reserved.
|
2014-04-29 06:42:26 +00:00
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file.
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
#ifndef V8_DATE_H_
|
|
|
|
#define V8_DATE_H_
|
|
|
|
|
2017-03-03 13:54:57 +00:00
|
|
|
#include "src/base/timezone-cache.h"
|
2014-06-03 08:12:43 +00:00
|
|
|
#include "src/globals.h"
|
2018-11-03 00:13:22 +00:00
|
|
|
#include "src/objects/smi.h"
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
namespace v8 {
|
|
|
|
namespace internal {
|
|
|
|
|
|
|
|
class DateCache {
|
|
|
|
public:
|
|
|
|
static const int kMsPerMin = 60 * 1000;
|
|
|
|
static const int kSecPerDay = 24 * 60 * 60;
|
|
|
|
static const int64_t kMsPerDay = kSecPerDay * 1000;
|
2015-12-30 23:54:25 +00:00
|
|
|
static const int64_t kMsPerMonth = kMsPerDay * 30;
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
// The largest time that can be passed to OS date-time library functions.
|
|
|
|
static const int kMaxEpochTimeInSec = kMaxInt;
|
|
|
|
static const int64_t kMaxEpochTimeInMs =
|
|
|
|
static_cast<int64_t>(kMaxInt) * 1000;
|
|
|
|
|
|
|
|
// The largest time that can be stored in JSDate.
|
|
|
|
static const int64_t kMaxTimeInMs =
|
|
|
|
static_cast<int64_t>(864000000) * 10000000;
|
|
|
|
|
2012-03-09 13:01:32 +00:00
|
|
|
// Conservative upper bound on time that can be stored in JSDate
|
|
|
|
// before UTC conversion.
|
2015-12-30 23:54:25 +00:00
|
|
|
static const int64_t kMaxTimeBeforeUTCInMs = kMaxTimeInMs + kMsPerMonth;
|
2012-03-09 13:01:32 +00:00
|
|
|
|
2012-03-09 12:07:29 +00:00
|
|
|
// Sentinel that denotes an invalid local offset.
|
|
|
|
static const int kInvalidLocalOffsetInMs = kMaxInt;
|
|
|
|
// Sentinel that denotes an invalid cache stamp.
|
|
|
|
// It is an invariant of DateCache that cache stamp is non-negative.
|
|
|
|
static const int kInvalidStamp = -1;
|
|
|
|
|
Reland of [date] Add ICU backend for timezone info behind a flag (patchset #1 id:1 of https://codereview.chromium.org/2811103002/ )
Reason for revert:
Reland with tests marked as off in no-i18n mode
Original issue's description:
> Revert of [date] Add ICU backend for timezone info behind a flag (patchset #17 id:320001 of https://codereview.chromium.org/2724373002/ )
>
> Reason for revert:
> Breaks noi18n:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/13314
>
> Original issue's description:
> > [date] Add ICU backend for timezone info behind a flag
> >
> > This patch implements a timezone backend which is based on ICU, rather
> > than operating system calls. It can be turned on by passing the
> > --icu-timezone-data flag. The goal here is to take advantage of ICU's
> > data, which is more complete than the data that some system calls expose.
> > For example, without any special code, this patch fixes the time zone
> > of Lord Howe Island to have a correct 30 minute DST offset, rather than
> > 60 minutes as the OS backends assume it to have.
> >
> > Unfortunately, the parenthized timezone name in Date.prototype.toString()
> > differs across platforms. This patch chooses the long timezone name,
> > which matches Windows behavior and might be the most intelligible, but
> > the web compatibility impact is unclear.
> >
> > BUG=v8:6031,v8:2137,v8:6076
> >
> > Review-Url: https://codereview.chromium.org/2724373002
> > Cr-Commit-Position: refs/heads/master@{#44562}
> > Committed: https://chromium.googlesource.com/v8/v8/+/b213f2399038a615cdfbfa0201cddc113d304018
>
> TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:6031,v8:2137,v8:6076
>
> Review-Url: https://codereview.chromium.org/2811103002
> Cr-Commit-Position: refs/heads/master@{#44565}
> Committed: https://chromium.googlesource.com/v8/v8/+/13ad50811024ace5623d5d4d13cea4ef21f4affd
TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,machenbach@chromium.org
BUG=v8:6031,v8:2137,v8:6076
Review-Url: https://codereview.chromium.org/2813863002
Cr-Commit-Position: refs/heads/master@{#44575}
2017-04-11 13:17:29 +00:00
|
|
|
DateCache();
|
2012-03-09 12:07:29 +00:00
|
|
|
|
2014-03-14 15:19:54 +00:00
|
|
|
virtual ~DateCache() {
|
2017-03-03 13:54:57 +00:00
|
|
|
delete tz_cache_;
|
2017-10-13 16:33:03 +00:00
|
|
|
tz_cache_ = nullptr;
|
2014-03-14 15:19:54 +00:00
|
|
|
}
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
// Clears cached timezone information and increments the cache stamp.
|
|
|
|
void ResetDateCache();
|
|
|
|
|
|
|
|
|
|
|
|
// Computes floor(time_ms / kMsPerDay).
|
|
|
|
static int DaysFromTime(int64_t time_ms) {
|
|
|
|
if (time_ms < 0) time_ms -= (kMsPerDay - 1);
|
|
|
|
return static_cast<int>(time_ms / kMsPerDay);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Computes modulo(time_ms, kMsPerDay) given that
|
|
|
|
// days = floor(time_ms / kMsPerDay).
|
|
|
|
static int TimeInDay(int64_t time_ms, int days) {
|
|
|
|
return static_cast<int>(time_ms - days * kMsPerDay);
|
|
|
|
}
|
|
|
|
|
2018-04-25 10:53:04 +00:00
|
|
|
// ECMA 262 - ES#sec-timeclip TimeClip (time)
|
|
|
|
static double TimeClip(double time);
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
// Given the number of days since the epoch, computes the weekday.
|
|
|
|
// ECMA 262 - 15.9.1.6.
|
|
|
|
int Weekday(int days) {
|
|
|
|
int result = (days + 4) % 7;
|
|
|
|
return result >= 0 ? result : result + 7;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool IsLeap(int year) {
|
|
|
|
return year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
|
|
|
|
}
|
|
|
|
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
// ECMA 262 - ES#sec-local-time-zone-adjustment
|
|
|
|
int LocalOffsetInMs(int64_t time, bool is_utc) {
|
|
|
|
return GetLocalOffsetFromOS(time, is_utc);
|
2012-03-09 12:07:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
const char* LocalTimezone(int64_t time_ms) {
|
|
|
|
if (time_ms < 0 || time_ms > kMaxEpochTimeInMs) {
|
|
|
|
time_ms = EquivalentTime(time_ms);
|
|
|
|
}
|
[date] Add a cache for timezone names to DateCache
To speed up Date.prototype.toString(), this patch adds a cache in
the DateCache for the string short name representing the time zone.
Because time zones in a particular location just have two short names
(for DST and standard time), and the DateCache already understands
whether a time is in DST or not, it is possible to keep the result
of OS::LocalTimezone around and select between the two based on
whether the time is DST or not.
In local microbenchmarks (calling Date.prototype.toString() in a
loop), I observed a 6-10% speedup with this patch. In the browser,
the speedup may be even greater as the system call needs to do
some extra work to break out of the sandbox. I don't think the
microbenchmark is extremely unrealistic; in any real program which
calls Date.prototype.toString() multiple times, the cache should
hit almost all of the time, as time zone changes are rare.
The proximate motivation for this patch was to enable ICU as a
backend for timezone information, which is drafted at
https://codereview.chromium.org/2724373002/
The ICU implementation of OS::LocalTimezone is even slower than
the system call one, but this patch makes their performance
indistinguishable on the microbenchmark.
In the tz database, many timezones actually do have a number of different
historical names. For example, America/Anchorage went through a number of
changes, from AST to AHST to YST to AKST. However, both ICU and the
Linux OS interfaces just report the modern timezone name in tests
for the appropriate timezone name, even for historical times. I can
see why this would be:
- For ICU, CLDR only has two short names in the data file: the one for
dst and non-dst
- For Linux, the timezone names do seem to make it into the
/etc/localtime file. However, glibc assumes there are only two relevant
names and selects between them, as you can see in its implementation
of localtime_r:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/time/tzset.c#L573
So, this cache should be valid until we switch to a more accurate source
of short timezone names.
BUG=v8:6031
Review-Url: https://codereview.chromium.org/2726253002
Cr-Commit-Position: refs/heads/master@{#43730}
2017-03-11 22:49:36 +00:00
|
|
|
bool is_dst = DaylightSavingsOffsetInMs(time_ms) != 0;
|
|
|
|
const char** name = is_dst ? &dst_tz_name_ : &tz_name_;
|
|
|
|
if (*name == nullptr) {
|
|
|
|
*name = tz_cache_->LocalTimezone(static_cast<double>(time_ms));
|
|
|
|
}
|
|
|
|
return *name;
|
2012-03-09 12:07:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ECMA 262 - 15.9.5.26
|
|
|
|
int TimezoneOffset(int64_t time_ms) {
|
|
|
|
int64_t local_ms = ToLocal(time_ms);
|
|
|
|
return static_cast<int>((time_ms - local_ms) / kMsPerMin);
|
|
|
|
}
|
|
|
|
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
// ECMA 262 - ES#sec-localtime-t
|
|
|
|
// LocalTime(t) = t + LocalTZA(t, true)
|
2012-03-09 12:07:29 +00:00
|
|
|
int64_t ToLocal(int64_t time_ms) {
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
return time_ms + LocalOffsetInMs(time_ms, true);
|
2012-03-09 12:07:29 +00:00
|
|
|
}
|
|
|
|
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
// ECMA 262 - ES#sec-utc-t
|
|
|
|
// UTC(t) = t - LocalTZA(t, false)
|
2012-03-09 12:07:29 +00:00
|
|
|
int64_t ToUTC(int64_t time_ms) {
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
return time_ms - LocalOffsetInMs(time_ms, false);
|
2012-03-09 12:07:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Computes a time equivalent to the given time according
|
|
|
|
// to ECMA 262 - 15.9.1.9.
|
|
|
|
// The issue here is that some library calls don't work right for dates
|
|
|
|
// that cannot be represented using a non-negative signed 32 bit integer
|
|
|
|
// (measured in whole seconds based on the 1970 epoch).
|
|
|
|
// We solve this by mapping the time to a year with same leap-year-ness
|
|
|
|
// and same starting day for the year. The ECMAscript specification says
|
|
|
|
// we must do this, but for compatibility with other browsers, we use
|
|
|
|
// the actual year if it is in the range 1970..2037
|
|
|
|
int64_t EquivalentTime(int64_t time_ms) {
|
|
|
|
int days = DaysFromTime(time_ms);
|
|
|
|
int time_within_day_ms = static_cast<int>(time_ms - days * kMsPerDay);
|
|
|
|
int year, month, day;
|
|
|
|
YearMonthDayFromDays(days, &year, &month, &day);
|
|
|
|
int new_days = DaysFromYearMonth(EquivalentYear(year), month) + day - 1;
|
|
|
|
return static_cast<int64_t>(new_days) * kMsPerDay + time_within_day_ms;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns an equivalent year in the range [2008-2035] matching
|
|
|
|
// - leap year,
|
|
|
|
// - week day of first day.
|
|
|
|
// ECMA 262 - 15.9.1.9.
|
|
|
|
int EquivalentYear(int year) {
|
|
|
|
int week_day = Weekday(DaysFromYearMonth(year, 0));
|
|
|
|
int recent_year = (IsLeap(year) ? 1956 : 1967) + (week_day * 12) % 28;
|
|
|
|
// Find the year in the range 2008..2037 that is equivalent mod 28.
|
|
|
|
// Add 3*28 to give a positive argument to the modulus operator.
|
|
|
|
return 2008 + (recent_year + 3 * 28 - 2008) % 28;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Given the number of days since the epoch, computes
|
|
|
|
// the corresponding year, month, and day.
|
|
|
|
void YearMonthDayFromDays(int days, int* year, int* month, int* day);
|
|
|
|
|
|
|
|
// Computes the number of days since the epoch for
|
|
|
|
// the first day of the given month in the given year.
|
|
|
|
int DaysFromYearMonth(int year, int month);
|
|
|
|
|
2016-01-05 11:05:41 +00:00
|
|
|
// Breaks down the time value.
|
|
|
|
void BreakDownTime(int64_t time_ms, int* year, int* month, int* day,
|
|
|
|
int* weekday, int* hour, int* min, int* sec, int* ms);
|
|
|
|
|
2012-03-09 12:07:29 +00:00
|
|
|
// Cache stamp is used for invalidating caches in JSDate.
|
|
|
|
// We increment the stamp each time when the timezone information changes.
|
|
|
|
// JSDate objects perform stamp check and invalidate their caches if
|
|
|
|
// their saved stamp is not equal to the current stamp.
|
2018-11-03 00:13:22 +00:00
|
|
|
Smi stamp() { return stamp_; }
|
2012-03-09 12:07:29 +00:00
|
|
|
void* stamp_address() { return &stamp_; }
|
|
|
|
|
|
|
|
// These functions are virtual so that we can override them when testing.
|
|
|
|
virtual int GetDaylightSavingsOffsetFromOS(int64_t time_sec) {
|
2012-03-09 13:01:32 +00:00
|
|
|
double time_ms = static_cast<double>(time_sec * 1000);
|
2017-03-03 13:54:57 +00:00
|
|
|
return static_cast<int>(tz_cache_->DaylightSavingsOffset(time_ms));
|
2012-03-09 12:07:29 +00:00
|
|
|
}
|
|
|
|
|
Reland "Implement a new spec for timezone offset calculation"
This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
2018-04-03 17:18:38 +00:00
|
|
|
virtual int GetLocalOffsetFromOS(int64_t time_ms, bool is_utc);
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
// The implementation relies on the fact that no time zones have
|
|
|
|
// more than one daylight savings offset change per 19 days.
|
|
|
|
// In Egypt in 2010 they decided to suspend DST during Ramadan. This
|
|
|
|
// led to a short interval where DST is in effect from September 10 to
|
|
|
|
// September 30.
|
|
|
|
static const int kDefaultDSTDeltaInSec = 19 * kSecPerDay;
|
|
|
|
|
|
|
|
// Size of the Daylight Savings Time cache.
|
|
|
|
static const int kDSTSize = 32;
|
|
|
|
|
|
|
|
// Daylight Savings Time segment stores a segment of time where
|
|
|
|
// daylight savings offset does not change.
|
|
|
|
struct DST {
|
|
|
|
int start_sec;
|
|
|
|
int end_sec;
|
|
|
|
int offset_ms;
|
|
|
|
int last_used;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Computes the daylight savings offset for the given time.
|
|
|
|
// ECMA 262 - 15.9.1.8
|
|
|
|
int DaylightSavingsOffsetInMs(int64_t time_ms);
|
|
|
|
|
|
|
|
// Sets the before_ and the after_ segments from the DST cache such that
|
|
|
|
// the before_ segment starts earlier than the given time and
|
|
|
|
// the after_ segment start later than the given time.
|
|
|
|
// Both segments might be invalid.
|
|
|
|
// The last_used counters of the before_ and after_ are updated.
|
|
|
|
void ProbeDST(int time_sec);
|
|
|
|
|
|
|
|
// Finds the least recently used segment from the DST cache that is not
|
|
|
|
// equal to the given 'skip' segment.
|
|
|
|
DST* LeastRecentlyUsedDST(DST* skip);
|
|
|
|
|
|
|
|
// Extends the after_ segment with the given point or resets it
|
|
|
|
// if it starts later than the given time + kDefaultDSTDeltaInSec.
|
|
|
|
inline void ExtendTheAfterSegment(int time_sec, int offset_ms);
|
|
|
|
|
|
|
|
// Makes the given segment invalid.
|
|
|
|
inline void ClearSegment(DST* segment);
|
|
|
|
|
|
|
|
bool InvalidSegment(DST* segment) {
|
|
|
|
return segment->start_sec > segment->end_sec;
|
|
|
|
}
|
|
|
|
|
2018-11-03 00:13:22 +00:00
|
|
|
Smi stamp_;
|
2012-03-09 12:07:29 +00:00
|
|
|
|
|
|
|
// Daylight Saving Time cache.
|
|
|
|
DST dst_[kDSTSize];
|
|
|
|
int dst_usage_counter_;
|
|
|
|
DST* before_;
|
|
|
|
DST* after_;
|
|
|
|
|
|
|
|
int local_offset_ms_;
|
|
|
|
|
|
|
|
// Year/Month/Day cache.
|
|
|
|
bool ymd_valid_;
|
|
|
|
int ymd_days_;
|
|
|
|
int ymd_year_;
|
|
|
|
int ymd_month_;
|
|
|
|
int ymd_day_;
|
2014-03-14 15:19:54 +00:00
|
|
|
|
[date] Add a cache for timezone names to DateCache
To speed up Date.prototype.toString(), this patch adds a cache in
the DateCache for the string short name representing the time zone.
Because time zones in a particular location just have two short names
(for DST and standard time), and the DateCache already understands
whether a time is in DST or not, it is possible to keep the result
of OS::LocalTimezone around and select between the two based on
whether the time is DST or not.
In local microbenchmarks (calling Date.prototype.toString() in a
loop), I observed a 6-10% speedup with this patch. In the browser,
the speedup may be even greater as the system call needs to do
some extra work to break out of the sandbox. I don't think the
microbenchmark is extremely unrealistic; in any real program which
calls Date.prototype.toString() multiple times, the cache should
hit almost all of the time, as time zone changes are rare.
The proximate motivation for this patch was to enable ICU as a
backend for timezone information, which is drafted at
https://codereview.chromium.org/2724373002/
The ICU implementation of OS::LocalTimezone is even slower than
the system call one, but this patch makes their performance
indistinguishable on the microbenchmark.
In the tz database, many timezones actually do have a number of different
historical names. For example, America/Anchorage went through a number of
changes, from AST to AHST to YST to AKST. However, both ICU and the
Linux OS interfaces just report the modern timezone name in tests
for the appropriate timezone name, even for historical times. I can
see why this would be:
- For ICU, CLDR only has two short names in the data file: the one for
dst and non-dst
- For Linux, the timezone names do seem to make it into the
/etc/localtime file. However, glibc assumes there are only two relevant
names and selects between them, as you can see in its implementation
of localtime_r:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/time/tzset.c#L573
So, this cache should be valid until we switch to a more accurate source
of short timezone names.
BUG=v8:6031
Review-Url: https://codereview.chromium.org/2726253002
Cr-Commit-Position: refs/heads/master@{#43730}
2017-03-11 22:49:36 +00:00
|
|
|
// Timezone name cache
|
|
|
|
const char* tz_name_;
|
|
|
|
const char* dst_tz_name_;
|
|
|
|
|
2014-06-30 13:25:46 +00:00
|
|
|
base::TimezoneCache* tz_cache_;
|
2012-03-09 12:07:29 +00:00
|
|
|
};
|
|
|
|
|
2015-09-30 13:46:56 +00:00
|
|
|
} // namespace internal
|
|
|
|
} // namespace v8
|
2012-03-09 12:07:29 +00:00
|
|
|
|
2018-02-02 12:05:19 +00:00
|
|
|
#endif // V8_DATE_H_
|