Logs for the RingoJS IRC channel,
as logged by ringostarr.
[08:25] <botic> i'm fixing the date's unit tests now. testAdd is easy to fix, the expected values have to be in utc like in other test cases.
[09:37] <hannesw> botic: any news about the timezone issue?
[09:57] <botic> hannesw: yes, i found the problem behind the test and fixing it right now
[09:57] <hannesw> botic: excellent!
[09:58] <botic> hannesw: it's a local time problem - like everything with js dates ;)
[09:58] <hannesw> yep
[10:43] <botic> hannesw: any ideas how to fix the daysInMonth problem?
[10:43] <hannesw> botic: nope. looks like an incompatibility between rhino and java dates
[10:43] <hannesw> it's strange. I think rhino Date behaves according to Ecma spec
[10:44] <botic> i tested utc-4 in canada and in brazil
[10:44] <hannesw> with what result?
[10:44] <botic> and in canada it worked, in brazil not
[10:44] <hannesw> weird
[10:45] <hannesw> maybe a daylight saving thing
[10:45] <botic> in brazil feb. 1904 had 31 days?!
[10:45] <hannesw> no, the date resolves to jan 31
[10:45] <hannesw> so what is feb 1 in js/rhino is jan 31 in java
[10:46] <hannesw> (not a whole day difference, just a few hours before midnight)
[10:46] <hannesw> ecmascript spec says date impl *may* take care of daylight saving time
[10:46] <hannesw> but of course, it has to be consistent
[10:47] <botic> yep, i read that some time ago
[10:48] <hannesw> it's weird that it only happens with year 2301
[10:48] <hannesw> is there anything special about that year?
[10:48] <botic> no, here it's 1904
[10:48] <hannesw> oh ok
[10:50] <botic> one solution: using a "normal" year for daysInMonth()
[10:50] <hannesw> hm but what is normal?
[11:17] <botic> argh, sorry, my fault... there was a typo it's just 2301 now
[11:17] <hannesw> hm, ok
[20:58] <oravecz> all tests are passing for me now on master
[22:14] <botic> oravecz: thx for testing! now the conversion between js date and java gregoriancalendar looks much better and works also with "exotic" dates. and the testcase is correct.