toBrowserTimeZone with ISO 8601 input

[carlludewig]

I was excited to see the inclusion of toBrowserTimeZone, but I'm unable to get it to work with ISO 8601 input. For example, $.format.date("2013-09-13T09:44:00Z", "d-MMM-yy hh:mm a") will return "13-Sep-13 09:44 AM" regardless of the browser time zone.

📌 #124

[phstc]

Could you test with

$.format.toBrowserTimeZone('2013-09-13T09:44:00Z', 'd-MMM-yy hh:mm a');

?

[carlludewig]

Ok. I just executed,

 console.log($.format.toBrowserTimeZone('2013-09-13T09:44:00Z', 'd-MMM-yy hh:mm a'));

On Safari in PDT. I got,

 13-Sep-13 09:44 AM

My current workaround is to use the built-in Date object to do the conversion. But it requires formatting the ISO date into one acceptable to Date():

 var value = '2013-09-13T09:44:00Z'; 
 var converted = new Date($.format.date(value, 'MMM dd yyyy HH:mm:ss ' + value.replace(/Z$/, '+0000').match(/[\+\-]\d\d\d\d$/))).toString();
 console.log($.format.date(converted, 'd-MMM-yy hh:mm a'));

And that seems to do the trick:

 13-Sep-13 02:44 AM

[carlludewig]

Here's my tweak to my copy of dateFormat:

        toBrowserTimeZone : function (value, format) {
            value = new Date(this.date(value, "MMM dd yyyy HH:mm:ss " + value.replace(/Z$/, "+0000").match(/[\+\-]\d\d\d\d$/))).toString();
            return this.date(value, format || "MM/dd/yyyy");
        }

[phstc]

@carlludewig didn't understand, isn't it working? I tested it when @arjunballa submitted the PR and it worked well.

[carlludewig]

Here's a snippet of the current source:

  toBrowserTimeZone : function(value, format) {
    return this.date(value, format || 'MM/dd/yyyy');
  }

It reads to me as a simple pass-through to the "date" function, unless there's something behind the scenes I'm missing. The unit test passes, but in that test case, it looks like the JS Date object is doing the heavy lifting before toBrowserTimeZone is called.

If I'm mistaken, that would be great, but I don't see it. Thanks.

[arjunballa]

I had similar code earlier where toBrowserTimeZone always creates a JS date object and passes to this.date() later I realized that this.date() always creates a JS date object and hence I removed that. I will check why it is not working and submit a PR.

Yes, the test case is passing because we are passing JS object to toBrowserTimeZone method

[arjunballa]

@carlludewig
My tweak
toBrowserTimeZone : function(value, format) {
return this.date(new Date(value), format || 'MM/dd/yyyy HH:mm:ss');
}

In order to convert browser timezone we always need to pass input date with timezone in it. Here are the expected input formats with which I tested

var date1 = "2013-09-14T23:22:33Z"; // Sat Sep 14 2013 16:22:33 PDT
var date2 = "2013-09-14T16:22:33.527-07:00"; // Sat Sep 14 2013 16:22:33 PDT
var date3 = "Sat Sep 14 2013 16:22:33 GMT-0700 (PDT)"; // Sat Sep 14 2013 16:22:33 PDT

$.format.toBrowserTimeZone(date1)
$.format.toBrowserTimeZone(date2)
$.format.toBrowserTimeZone(date3)

Can you please verify if this fix works in your case?

[arjunballa]

@carlludewig @phstc If you are happy with the fix I can submit a PR.

[carlludewig]

That will work for me. Thanks. My initial attempt was more complicated because Javascript Date() doesn't take an ISO 8601 date such as 2013-09-14T16:22:33-0700 with 4 time zone digits without a colon. But that's not dateFormat's problem. So we'll reformat our ISO dates slightly and it will work fine. Thanks.

[phstc]

@arjunballa Thanks a lot 😄 It works for me. Could you update the README, please?

[arjunballa]

@carlludewig
Can you please explain "ISO 8601 date such as 2013-09-14T16:22:33-0700 with 4 time zone digits without a colon".
The supported input format are
String representing date in ISO time ("2013-09-14T23:22:33Z") or String representing default JAXB formatting of java.util.Date ("2013-09-14T16:22:33.527-07:00") or String representing Unix Timestamp (Sat Sep 14 2013 16:22:33 GMT-0700 (PDT)) or javascript date object.

Current method doesn't support "2013-09-14T16:22:33-0700" timezone without colon. May I know where from you are getting this string?

[carlludewig]

@arjunballa Yes, you are correct, it is not a supported input format, which is why we're reformatting in our app.

A year ago or so we standardized on ISO 8601 dates in our REST APIs in the format I mentioned ("2013-09-14T16:22:33-0700"). We omitted the colon in the time zone (e.g., "07:00") because the Java SimpleDateFormat class doesn't support it on the server side (the "Z" format value only produces 4 digits no colon). However, Javascript Date() doesn't accept this, so we need to adjust to this reality in our app. Hope that makes things clear.

My ideal would be to have the SimpleDateFormat on the server side and my date packages on the client completely compatible, but that's not realistic I think.

[phstc]

@arjunballa @carlludewig The PR #51 was merged, thank you all. 😄