sl-ember-components icon indicating copy to clipboard operation
sl-ember-components copied to clipboard

Integration | Component | sl date time: Date values applied correctly

Open notmessenger opened this issue 8 years ago • 5 comments

Occurring in https://travis-ci.org/softlayer/sl-ember-components/jobs/117349289

Integration | Component | sl date time: Date values applied correctly

not ok 133 PhantomJS 1.9 - Integration | Component | sl date time: Date values applied correctly
    ---
        actual: >
            2015-12-20
        expected: >
            2015-12-21
        stack: >
                at http://localhost:7357/assets/test-support.js:3426
                at http://localhost:7357/assets/tests.js:8398
                at wrapper (http://localhost:7357/assets/test-support.js:38868)
                at runTest (http://localhost:7357/assets/test-support.js:2763)
                at http://localhost:7357/assets/test-support.js:2748
                at http://localhost:7357/assets/test-support.js:2890
                at process (http://localhost:7357/assets/test-support.js:2550)
                at begin (http://localhost:7357/assets/test-support.js:2532)
                at http://localhost:7357/assets/test-support.js:2592
        message: >
            Default date string matches default date pattern
        Log: |

notmessenger avatar Mar 21 '16 00:03 notmessenger

taking this.

erangeles avatar Mar 21 '16 15:03 erangeles

@notmessenger this is not reproducible in the v0.12.0 branch(cloned from scratch). can you try re-running the build? all tests pass

erangeles avatar Mar 21 '16 21:03 erangeles

@erangeles I re-ran the the build with the same results. Are you running the same version of Node? Maybe leap year isn't being taken into account somehow in the date test logic?

notmessenger avatar Mar 22 '16 11:03 notmessenger

We have now switched from using TravisCI to CircleCI. This same error occurred in CircleCI in https://circleci.com/gh/notmessenger/sl-ember-components/11 but is now currently passing.

notmessenger avatar Apr 07 '16 11:04 notmessenger

At the moment it's looking like this is a difference in the values generated by window.moment().subtract( 3, 'months' ).toISOString() and window.moment().subtract( 3, 'months' ) where if such calls are made late into the evening, near midnight, the former call returns 2016-01-08T04:13:09.856Z while the latter returns 2016-01-07

notmessenger avatar Apr 08 '16 22:04 notmessenger