4

As the timestamp recently turns over 1.5 billions, a strange (and apparently random) bug arises in one of my script.

I got to initialize a dateTimePicker, I did this :

$('#datepickerfield').data('DateTimePicker').date(new Date(1502173800000));

1502173800000 is of course a millisecond timestamp. Most of the time, it just works.

But as you can see, somehow 15021738... could be (and in fact, sometime, IS) wrongly interpreted as 15/02/1738 (french dd/mm/yyyy format)... That was not the case with timestamps beginning with 1499 or even 1500 and the bug just appears at the moment timestamps start to begin with 1501 (leads to january, the 15th) and so on.

It does appear RANDOMLY which is very annoying and almost impossible to fix on the server side (too many cases to consider, even a date like 15/02/1738 could be legit in some contexts)

So i got two questions :

  1. has anyone ever experienced that ? Is this a know javascript bug (i've searched but did not found any complaint on this matter.)
  2. how could i replace this call by a better one ? I'm using Angular v1.5, Moment.js, JQuery 2.x - this precise call is in an Angular controller.

Thanks for your attention

Denis

Denis Valdenaire aka Joe Linux
  • 312
  • 1
  • 2
  • 11
  • Can you create a demo to reproduce that? `new Date(1502173800000)` returns `Tue Aug 08 2017 09:30:00 GMT+0300 (EEST)` which is probably correct. – Ionică Bizău Aug 22 '17 at 07:03
  • Tried over 50 times and always have a good value. Could you reproduce this bug ? – sheplu Aug 22 '17 at 07:05
  • *even a date like 15/02/1738 could be legit in some contexts* Maybe so, but not when you're using millisecond timestamps as the count starts on 01/01/1970. – Robby Cornelissen Aug 22 '17 at 07:05
  • 3
    If you pass the value as type Number, it must be interpreted correctly as a time value. Otherwise, see [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) BTW, d/m/y is not "french" format, it's pretty much used by everyone except those from USA (along with y/m/d). – RobG Aug 22 '17 at 07:08
  • @RobbyCornelissen—well, 15/02/1738 would be -7317302400000 (UTC). ;-) – RobG Aug 22 '17 at 07:11
  • @IonicăBizău the main part of the problem is that I just can't reproduce this behaviour - I don't even know how it could be possible to fail such a conversion, but my logs shows that such dates are posted by angular - and clients reports the DateTimePicker displays dates like 15/02/7383 (and currently these are dates like 15/03/....) (eventually it will be fixed when timestamps begin by 1513... on December the 11th) – Denis Valdenaire aka Joe Linux Aug 22 '17 at 07:59

1 Answers1

1

It turns out that the problem has nothing to do with Date (I replaced the call with moment.unix(timestamp), and the problem was still there).

First, it was not so random after all. Conversion from timestamp to date happens only when "possible" i.e. when the four first digits looks like a possible "ddmm" (since 1501...), the four following digits like a "yyyy" (almost always) and the 2 following like "hh", that is between 0 and 23.

- HAPPY END -

This strange parsing error is due to an option of datetimepicker (this one here : http://eonasdan.github.io/bootstrap-datetimepicker/) that is false by default.

useStrict: true

For details (the option itself influences the Moment.js library), see http://eonasdan.github.io/bootstrap-datetimepicker/Options/#usestrict

Denis Valdenaire aka Joe Linux
  • 312
  • 1
  • 2
  • 11