Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Fix iso8601 parsing in Safari #159

Closed
wants to merge 1 commit into from

2 participants

@Manduro

Previous parsing result:
2014/01/09 01:06:21 UTC +0100

New parsing result:
2014/01/09 01:06:21 UTC+0100

Only in Safari, new Date("2014/01/09 01:06:21 UTC +0100") results in a "Invalid Date". Safari might even be right about not accepting this format.

When removing the space between UTC and the timezone designation, Safari parses the date correctly, as do other browsers.

A test page can be found here: http://jsfiddle.net/4aYGm/7/

@Manduro Manduro Fix iso8601 parsing in Safari
Previous parsing result:
2014/01/09 01:06:21 UTC +0100

New parsing result:
2014/01/09 01:06:21 UTC+0100

Only in Safari, new Date("2014/01/09 01:06:21 UTC +0100") results in a "Invalid Date". Safari might even be right about not accepting this format.

When removing the space between UTC and the timezone designation, Safari parses the date correctly, as do other browsers.
a272ddb
@rmm5t
Owner

Hmm. I'm confused by this. Can you please explain why the current Timeago test suite passes 100% on Safari? Maybe we're missing an important test, but I will need to see a failing test before I'm willing to pull this change in.

http://timeago.yarp.com/test/

_jquery-timeago_test_suite

@Manduro

I've dug a little deeper and it turns out the website where I had trouble is using incorrect ISO8601 timestamps.

2013-12-18T14:53:41Z+0100 instead of the correct 2013-12-18T14:53:41+0100

When using the correct format, everything works fine. So I was a little too fast to blame it on timeago, sorry :).

@Manduro Manduro closed this
@rmm5t
Owner

@Manduro Thanks for following-through, adding info, and closing this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 9, 2014
  1. @Manduro

    Fix iso8601 parsing in Safari

    Manduro authored
    Previous parsing result:
    2014/01/09 01:06:21 UTC +0100
    
    New parsing result:
    2014/01/09 01:06:21 UTC+0100
    
    Only in Safari, new Date("2014/01/09 01:06:21 UTC +0100") results in a "Invalid Date". Safari might even be right about not accepting this format.
    
    When removing the space between UTC and the timezone designation, Safari parses the date correctly, as do other browsers.
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 2 deletions.
  1. +2 −2 jquery.timeago.js
View
4 jquery.timeago.js
@@ -106,8 +106,8 @@
s = s.replace(/\.\d+/,""); // remove milliseconds
s = s.replace(/-/,"/").replace(/-/,"/");
s = s.replace(/T/," ").replace(/Z/," UTC");
- s = s.replace(/([\+\-]\d\d)\:?(\d\d)/," $1$2"); // -04:00 -> -0400
- s = s.replace(/([\+\-]\d\d)$/," $100"); // +09 -> +0900
+ s = s.replace(/([\+\-]\d\d)\:?(\d\d)/,"$1$2"); // -04:00 -> -0400
+ s = s.replace(/([\+\-]\d\d)$/,"$100"); // +09 -> +0900
return new Date(s);
},
datetime: function(elem) {
Something went wrong with that request. Please try again.