0

The following outputs a time that is 4 hours less than what was input:

X = new Date('2015-07-09T14:18:12.430')
$('body').append(X)
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
Salman A
  • 229,425
  • 77
  • 398
  • 489
Phillip Senn
  • 43,069
  • 83
  • 242
  • 359
  • it's work fine for me : `Thu Jul 09 2015 14:18:12`, show me your output please. – Zakaria Acharki Jul 09 '15 at 19:41
  • possible duplicate of [How to format a JavaScript date](http://stackoverflow.com/questions/3552461/how-to-format-a-javascript-date) – DLeh Jul 09 '15 at 19:42
  • 1
    You haven't specified a timezone in your string, in this case it's being interpreted as `+0000` because it's in the _ISO 8601_ format. The _toString_ method of _Date_ instances will output your local time – Paul S. Jul 09 '15 at 19:42
  • @ZakariaAcharki your local time is GMT so you're not seeing a transformation – Paul S. Jul 09 '15 at 19:46

3 Answers3

1

When you omit the timezone information on the end of an ISO 8601 formatted date-time the majority of computer implementations default to +0000, this means Date interprets 2015-07-09T14:18:12.430 the same as 2015-07-09T14:18:12.430+0000 or 2015-07-09T14:18:12.430Z

It looks like you were expecting it to be interpreted as your local time rather than in UTC, you have 3 options

  1. Append your local timezone offset to the end
  2. Write it differently so it will parse as you expect
  3. Create a second Date using the details from the UTC fields of the first Date
function myParser(iso_style) {
    var d = new Date(iso_style);
    return new Date(
        d.getUTCFullYear(),
        d.getUTCMonth(),
        d.getUTCDate(),
        d.getUTCHours(),
        d.getUTCMinutes(),
        d.getUTCSeconds(),
        d.getUTCMilliseconds()
    );
}

You can't simply adjust by your local offset as you would experience unexpected behaviour if the time crosses a date that would change that offset e.g. a daylight savings boundry


As Salman A's answer points out the current ES 6 Draft defines that an omitted timezone should be interpreted as meaning the client's local timezone. This will make the behaviour inconsistent as different JavaScript implementations change over so I strongly recommend you always use a timezone when writing ISO 8601.

Community
  • 1
  • 1
Paul S.
  • 58,277
  • 8
  • 106
  • 120
1

When you do no specify the timezone:

ECMAScript-5 compliant browsers will assume UTC timezone:

The value of an absent time zone offset is "Z".

ECMAScript-6 compliant browsers will assume local timezone:

If the time zone offset is absent, the date-time is interpreted as a local time.


Use the long Date constructor which assumes local timezone:

var X = new Date(2015, 7 - 1, 9, 14, 18, 12, 430);
alert(X);
Salman A
  • 229,425
  • 77
  • 398
  • 489
  • Yeah, you gotta love how JavaScript is 0 based. – Phillip Senn Jul 09 '15 at 20:03
  • @Phillip Lots of languages use `0`-based months, _JavaScript_, _Java_, _C_. It comes from that computers start counting from `0` and often people want the month name. It's similar with the day of the week being `0` (_Sunday_) to `6` (_Saturday_). Personally I would prefer it to be consistent though, as months are the "odd one out" in the constructor. – Paul S. Jul 09 '15 at 20:17
  • 1
    If _ES 6_ stays like this until it's out of draft it will make the behaviour inconsistant as implementations change so I strongly recommend you use a timezone when writing _ISO 8601_ – Paul S. Jul 09 '15 at 20:19
  • How do I use a timezone in the input string? – Phillip Senn Jul 10 '15 at 14:23
  • Oh, it looks like all I have to do is add -04:00 to the end of my string! Yay! – Phillip Senn Jul 10 '15 at 14:32
0

A quick and dirty workaround:

X = new Date('2015-07-09T14:18:12.430');
$('body').append( X.toString().split('GMT')[0] );

It works by turning the date object into a string, then splitting it into an array around the pattern GMT. So you would have 2 elements in the array: Thu Jul 09 2015 10:18:12 and 0400 (EDT). Since you want to drop everything after the GMT, you just use the element in the 0 index of the array

I misunderstood the question. If you use X.toUTCString(), it may fix your issue.

YazanLpizra
  • 510
  • 10
  • 31