From: Pietro <com...@gm...> - 2018-05-25 10:36:58
|
Hi all, I am wresting with a strange behaviour in my unit test below: class test { public void passingTest2() { TimeZone.setDefault(TimeZone.getTimeZone("EST")); Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101);// Eastern Standard Time GMT-5 LocalDate localDate = new LocalDate(date); assertEquals(new LocalDate(2016, 1, 1), localDate); } @Test public void failingTest2() { TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern European Time GMT+2 Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101); LocalDate localDate = new LocalDate(date); System.out.println(date.toString()); System.out.println(DateTimeZone.getDefault()); System.out.println(localDate); assertEquals(new LocalDate(2016, 1, 1), localDate); } } The method failingTest() will fail only if the whole class is run, namely the two tests are executed as they appear in the file, and it does not fail if it is the only executed test. I am wondering if it has something to do with some static initialization of the LocalDate class and its dependencies. Another question I have is about the TimeZone.setDefault(..) - as such class comes from the java.util package I guess it is not impacting in any way the LocalDate's computation, am I right ? Thanks in advance, Pietro |
From: Pietro <com...@gm...> - 2018-05-25 10:44:10
|
Hi all, Sorry, I've made a mistake and I have mixed some of my code with the standard java.util.* and joda, I am reposting the unit tests, which fail as described earlier. @Test public void passingTest2() { TimeZone.setDefault(TimeZone.getTimeZone("EST")); Date date = new Date(2016 - 1900, 1 - 1, 1); LocalDate localDate = new LocalDate(date); assertEquals(new LocalDate(2016, 1, 1), localDate); } @Test public void failingTest2() { TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern European Time GMT+2 Date date = new Date(2016 - 1900, 1 - 1, 1); LocalDate localDate = new LocalDate(date); System.out.println(date.toString()); System.out.println(DateTimeZone.getDefault()); System.out.println(localDate); assertEquals(new LocalDate(2016, 1, 1), localDate); } On Fri, May 25, 2018 at 11:36 AM, Pietro < com...@gm...> wrote: > Hi all, > > I am wresting with a strange behaviour in my unit test below: > > class test { > > public void passingTest2() { > TimeZone.setDefault(TimeZone.getTimeZone("EST")); > Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101);// Eastern > Standard Time GMT-5 > LocalDate localDate = new LocalDate(date); > assertEquals(new LocalDate(2016, 1, 1), localDate); > } > > @Test > public void failingTest2() { > TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern > European Time GMT+2 > Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101); > LocalDate localDate = new LocalDate(date); > > System.out.println(date.toString()); > System.out.println(DateTimeZone.getDefault()); > System.out.println(localDate); > assertEquals(new LocalDate(2016, 1, 1), localDate); > } > > } > > > The method failingTest() will fail only if the whole class is run, namely > the two tests are executed as they appear in the file, and it does not fail > if it is the only executed test. I am > wondering if it has something to do with some static initialization of the > LocalDate class and its dependencies. > > Another question I have is about the TimeZone.setDefault(..) - as such > class comes from the java.util package I guess it is not impacting in any > way the LocalDate's computation, am I right ? > > Thanks in advance, > Pietro > > |
From: Stephen C. <sco...@jo...> - 2018-05-25 10:52:20
|
new LocalDate() will not work for time-zones ahead of UTC+00:00 Use LocalDate.fromDateFields() instead. Stephen On 25 May 2018 at 11:44, Pietro <com...@gm...> wrote: > Hi all, > > Sorry, I've made a mistake and I have mixed some of my code with the > standard java.util.* and joda, I am reposting the unit tests, which fail as > described earlier. > > @Test > public void passingTest2() { > TimeZone.setDefault(TimeZone.getTimeZone("EST")); > Date date = new Date(2016 - 1900, 1 - 1, 1); > LocalDate localDate = new LocalDate(date); > assertEquals(new LocalDate(2016, 1, 1), localDate); > } > > @Test > public void failingTest2() { > TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern European > Time GMT+2 > > Date date = new Date(2016 - 1900, 1 - 1, 1); > LocalDate localDate = new LocalDate(date); > > System.out.println(date.toString()); > System.out.println(DateTimeZone.getDefault()); > System.out.println(localDate); > assertEquals(new LocalDate(2016, 1, 1), localDate); > } > > > > On Fri, May 25, 2018 at 11:36 AM, Pietro > <com...@gm...> wrote: >> >> Hi all, >> >> I am wresting with a strange behaviour in my unit test below: >> >> class test { >> >> public void passingTest2() { >> TimeZone.setDefault(TimeZone.getTimeZone("EST")); >> Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101);// Eastern >> Standard Time GMT-5 >> LocalDate localDate = new LocalDate(date); >> assertEquals(new LocalDate(2016, 1, 1), localDate); >> } >> >> @Test >> public void failingTest2() { >> TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern >> European Time GMT+2 >> Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101); >> LocalDate localDate = new LocalDate(date); >> >> System.out.println(date.toString()); >> System.out.println(DateTimeZone.getDefault()); >> System.out.println(localDate); >> assertEquals(new LocalDate(2016, 1, 1), localDate); >> } >> >> } >> >> >> The method failingTest() will fail only if the whole class is run, namely >> the two tests are executed as they appear in the file, and it does not fail >> if it is the only executed test. I am >> wondering if it has something to do with some static initialization of the >> LocalDate class and its dependencies. >> >> Another question I have is about the TimeZone.setDefault(..) - as such >> class comes from the java.util package I guess it is not impacting in any >> way the LocalDate's computation, am I right ? >> >> Thanks in advance, >> Pietro >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Pietro <com...@gm...> - 2018-05-25 11:21:48
|
On Fri, May 25, 2018 at 11:51 AM, Stephen Colebourne <sco...@jo...> wrote: > new LocalDate() will not work for time-zones ahead of UTC+00:00 > > Use LocalDate.fromDateFields() instead. > > Stephen > But why does it not fail when run in isolation ? Different question, documentation goes: public LocalDate(Object instant) Constructs an instance from an Object that represents a datetime. The time zone will be retrieved from the object if possible, otherwise the default time zone will be used. Therefore it takes into account the timezone, does it consider the date is getting in a certain timezone and it adjusts that to UTC for its internal representation ? I am probably a bit confused by the fact that at the beginning the LocalDate docs states "LocalDate is an immutable datetime class representing a date without a time zone." Which means, UTC ? Thanks in advance. > On 25 May 2018 at 11:44, Pietro <com...@gm...> wrote: >> Hi all, >> >> Sorry, I've made a mistake and I have mixed some of my code with the >> standard java.util.* and joda, I am reposting the unit tests, which fail as >> described earlier. >> >> @Test >> public void passingTest2() { >> TimeZone.setDefault(TimeZone.getTimeZone("EST")); >> Date date = new Date(2016 - 1900, 1 - 1, 1); >> LocalDate localDate = new LocalDate(date); >> assertEquals(new LocalDate(2016, 1, 1), localDate); >> } >> >> @Test >> public void failingTest2() { >> TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern European >> Time GMT+2 >> >> Date date = new Date(2016 - 1900, 1 - 1, 1); >> LocalDate localDate = new LocalDate(date); >> >> System.out.println(date.toString()); >> System.out.println(DateTimeZone.getDefault()); >> System.out.println(localDate); >> assertEquals(new LocalDate(2016, 1, 1), localDate); >> } >> >> >> >> On Fri, May 25, 2018 at 11:36 AM, Pietro >> <com...@gm...> wrote: >>> >>> Hi all, >>> >>> I am wresting with a strange behaviour in my unit test below: >>> >>> class test { >>> >>> public void passingTest2() { >>> TimeZone.setDefault(TimeZone.getTimeZone("EST")); >>> Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101);// Eastern >>> Standard Time GMT-5 >>> LocalDate localDate = new LocalDate(date); >>> assertEquals(new LocalDate(2016, 1, 1), localDate); >>> } >>> >>> @Test >>> public void failingTest2() { >>> TimeZone.setDefault(TimeZone.getTimeZone("EET"));// Eastern >>> European Time GMT+2 >>> Date date = LegacyDateFormat.YYYYMMDD.asDate(20160101); >>> LocalDate localDate = new LocalDate(date); >>> >>> System.out.println(date.toString()); >>> System.out.println(DateTimeZone.getDefault()); >>> System.out.println(localDate); >>> assertEquals(new LocalDate(2016, 1, 1), localDate); >>> } >>> >>> } >>> >>> >>> The method failingTest() will fail only if the whole class is run, namely >>> the two tests are executed as they appear in the file, and it does not fail >>> if it is the only executed test. I am >>> wondering if it has something to do with some static initialization of the >>> LocalDate class and its dependencies. >>> >>> Another question I have is about the TimeZone.setDefault(..) - as such >>> class comes from the java.util package I guess it is not impacting in any >>> way the LocalDate's computation, am I right ? >>> >>> Thanks in advance, >>> Pietro >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |