4

I am investigating an issue involving the conversion of serialized UTC dates in to JavaScript date objects; I have read a few questions on this topic already but I am still unclear.

Firstly let me say that I am in the UK. If I take for example the UTC epoch 1473805800000, which is Tue, 13 Sep 2016 22:30:00 GMT, then use that value to create a JavaScript date:

var date = new Date(1473805800000);
console.log(date);

The console logs:

Tue Sep 13 2016 23:30:00 GMT+0100 (GMT Summer Time)

I.e. the browser has recognised that an extra hour needs to be added for DST.

My question is, if I were to run this same code again after the 30th October when the clocks have gone back, would I still get the same result of 23:30, or would it be 22:30 as if it were GMT? In other words, has the browser added an hour because the subject date is DST or because we are currently in DST?

I'm prevented from altering my work station's system clock by group policy, otherwise I would skip it forward in time and test this myself.

Lee D
  • 12,551
  • 8
  • 32
  • 34
  • This might help you: https://stackoverflow.com/questions/4631928/convert-utc-epoch-to-local-date-with-javascript – Derek 朕會功夫 Sep 15 '16 at 17:10
  • http://stackoverflow.com/questions/11887934/check-if-daylight-saving-time-is-in-effect-and-if-it-is-for-how-many-hours – jollarvia Sep 15 '16 at 17:12
  • 1
    1473805800000 is a number, the [*ECMAScript Date epoch*](http://ecma-international.org/ecma-262/7.0/index.html#sec-time-values-and-time-range) is 1970-01-01T00:00:00Z. ;-) – RobG Sep 15 '16 at 23:35

2 Answers2

9

Javascript Date objects use a time value that is an offset in milliseconds since 1970-01-01T00:00:00Z. It is always UTC.

If the Date constructor is given a single number argument, it is treated as a UTC time value, so represents the same instant in time regardless of system time zone settings.

When you use console.log(date), the built–in toString method is called which generates an implementation dependent string, generally using the current time zone setting of the host system to create a convenient, human readable string.

The current daylight saving rules in the system are used to determine the offset to use for "local" time, so if the date changes from a time when daylight saving applies to one when it doesn't, the time zone offset will be similarly adjusted (note that daylight saving offsets aren't always 1 hour). It does not matter what the current system offset is, the one used is based on the setting for the date and time that the time value represents.

Also, Date objects are very simple, they're just a time value. The time zone offset comes from system settings, it's not a property of the Date itself.

So, given:

My question is, if I were to run this same code again after the 30th October when the clocks have gone back, would I still get the same result of 23:30, or would it be 22:30 as if it were GMT?

the answer is "yes", it will still be 23:30 since on 13 September BST applies. It doesn't matter when the code is run, only what the system offset setting is for that date.

RobG
  • 142,382
  • 31
  • 172
  • 209
1

In your case, the Date was created using epoch 1473805800000 and converted to your timezone GMT+0100. Epoch is always UTC time, therefore it was read as UTC and converted to your current timezone.

On September 13 2016, GMT+01 had summer time, therefore it was considered in the calculus.

In my case, I get the following, running the same code as yours:

Thu Sep 15 2016 14:13:14 GMT-0300 (E. South America Standard Time)
Vitor Durante
  • 950
  • 8
  • 25
  • An epoch is a benchmark that is used for relative measurements. For ECMAScript time values, the epoch is 1970-01-01T00:00:00Z. If used as a time value, the number 1473805800000 is an offset in milliseconds from the epoch that represents 2016-09-13T22:30:00.000Z. – RobG Sep 16 '16 at 13:33