Tom Eugelink comments

Results 81 comments of


                                            Tom Eugelink

Start-of-period loop corrupts start datetime

I can reproduce the behavior: ``` Calendar cal = Calendar.getInstance(); cal.setTimeInMillis(1572829200000l); for (int i = 0; i < 150; i++) { cal.add(Calendar.DATE, 1); System.out.println("cal=" + cal.toInstant()); } ```

Start-of-period loop corrupts start datetime

ZonedDateTime in Zulu does not show this behavior, but also ignores DST: ``` ZonedDateTime zonedDateTime = ZonedDateTime.parse("2020-03-24T01:00:00Z"); for (int i = 0; i < 365; i++) { zonedDateTime = zonedDateTime.plusDays(1);...

Start-of-period loop corrupts start datetime

I am uncertain what the intended behavior of getDates is; does it need to take DST into account or not? But it certainly seems it could benefit from a (partial)...

Start-of-period loop corrupts start datetime

I have checkout out the default branch (develop) which is indeed 3.0.20-develop-SNAPSHOT. Under which branch can I find the 4.x?

Start-of-period loop corrupts start datetime

Okay! My code already uses JSR 310, so I could strip out a lot of conversion, but at the same time it is a major refactor. Especially the switching between...

Start-of-period loop corrupts start datetime

Ok. That puts me in a pickle. My application (TeslaTasks) connects to Google calendar, so being able to parse its glitches is of great importance. AFAIK JSR310 does not have...

Start-of-period loop corrupts start datetime

Interesting; I had hope to just replace the increment method using JSR310, but you see similar strange behavior: 2020-03-27T01:00:00Z = 2020-03-27T02:00+01:00[Europe/Rome] -> 2020-03-28T02:00+01:00[Europe/Rome] 2020-03-28T01:00:00Z = 2020-03-28T02:00+01:00[Europe/Rome] -> 2020-03-29T03:00+02:00[Europe/Rome] ... 2020-10-23T01:00:00Z...