You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(64) |
May
(62) |
Jun
(33) |
Jul
(61) |
Aug
(75) |
Sep
(61) |
Oct
(124) |
Nov
(18) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(42) |
Feb
(19) |
Mar
(12) |
Apr
(34) |
May
(10) |
Jun
(4) |
Jul
(23) |
Aug
(24) |
Sep
(12) |
Oct
(48) |
Nov
(36) |
Dec
(48) |
2004 |
Jan
(26) |
Feb
(19) |
Mar
(21) |
Apr
(14) |
May
(9) |
Jun
(19) |
Jul
(44) |
Aug
(46) |
Sep
(27) |
Oct
(23) |
Nov
(30) |
Dec
(46) |
2005 |
Jan
(17) |
Feb
(36) |
Mar
(31) |
Apr
(53) |
May
(27) |
Jun
(20) |
Jul
(17) |
Aug
(48) |
Sep
(88) |
Oct
(55) |
Nov
(20) |
Dec
(50) |
2006 |
Jan
(36) |
Feb
(59) |
Mar
(39) |
Apr
(14) |
May
(19) |
Jun
(26) |
Jul
(54) |
Aug
(50) |
Sep
(19) |
Oct
(19) |
Nov
(37) |
Dec
(25) |
2007 |
Jan
(31) |
Feb
(33) |
Mar
(16) |
Apr
(9) |
May
(20) |
Jun
(30) |
Jul
(6) |
Aug
(48) |
Sep
(8) |
Oct
(20) |
Nov
(15) |
Dec
(21) |
2008 |
Jan
(49) |
Feb
(12) |
Mar
(31) |
Apr
(10) |
May
(25) |
Jun
(23) |
Jul
(22) |
Aug
(15) |
Sep
(27) |
Oct
(27) |
Nov
(28) |
Dec
(20) |
2009 |
Jan
(14) |
Feb
(7) |
Mar
(34) |
Apr
(10) |
May
(14) |
Jun
(2) |
Jul
(25) |
Aug
(8) |
Sep
(14) |
Oct
(17) |
Nov
(7) |
Dec
(15) |
2010 |
Jan
(4) |
Feb
(35) |
Mar
(21) |
Apr
(31) |
May
(1) |
Jun
(13) |
Jul
(28) |
Aug
(14) |
Sep
(19) |
Oct
(6) |
Nov
(15) |
Dec
(15) |
2011 |
Jan
(29) |
Feb
(12) |
Mar
(8) |
Apr
(21) |
May
(40) |
Jun
(12) |
Jul
(24) |
Aug
(19) |
Sep
(29) |
Oct
(21) |
Nov
(18) |
Dec
(30) |
2012 |
Jan
(10) |
Feb
(18) |
Mar
(19) |
Apr
(16) |
May
(15) |
Jun
(12) |
Jul
(9) |
Aug
(3) |
Sep
(16) |
Oct
(11) |
Nov
(8) |
Dec
|
2013 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
(7) |
Jun
(8) |
Jul
(20) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nepomuk S. <nep...@mu...> - 2013-01-26 22:23:03
|
Hi, Joda Time has a lot of nice convenient methods. However one is missing to iterate nicely over Intervals (or Durations, Periods). Normally you would do somethink like Interval interval = ...; Days days = Days. daysBetween(interval.getStart(), interval.getEnd()); for(int i=0; i < days.getDays(); i++) { // do something } or adding up DateTimes and compare, etc. It would be nice to have an iterator for this. Like: Iterator<DateTime> iter = Intervals.daysIn(interval); So I can call for(DateTime day : Intervals.daysIn(interval)) { // work with day } what do you think? Muki |
From: Stephen C. <sco...@jo...> - 2013-01-04 17:54:02
|
If we are going to make this change it will have to be v3.0. And we should release a v2.2 first. Stephen On 4 January 2013 16:32, Brian S O'Neill <br...@gm...> wrote: > In Joda-time 2.0, changes were made to make the code compliant with the > Java 5 memory model, but without breaking compatibility. The solution > was to define several fields as volatile, because declaring them as > final would break subclasses or serialization. > > Making the BaseDateTime fields volatile has a measurable performance > impact, nullifying (or worse) many of the performance gains Joda-time > has over the JDK date classes. It's possible to make these fields final > while still preserving serialization compatibility. The trick is to use > special object stream features. > > For this to work, the field definitions need to be moved to all the > subclasses, and the get/setMillis need to be abstract. The object stream > stuff also needs to move to the subclasses. > > There's one little issue: These changes break compatibility for anyone > that is extending BaseDateTime. Although this is an implementation > package, and so no one _should_ be extending it, is anyone out there > actually doing this? > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: Brian S O'N. <br...@gm...> - 2013-01-04 16:32:40
|
In Joda-time 2.0, changes were made to make the code compliant with the Java 5 memory model, but without breaking compatibility. The solution was to define several fields as volatile, because declaring them as final would break subclasses or serialization. Making the BaseDateTime fields volatile has a measurable performance impact, nullifying (or worse) many of the performance gains Joda-time has over the JDK date classes. It's possible to make these fields final while still preserving serialization compatibility. The trick is to use special object stream features. For this to work, the field definitions need to be moved to all the subclasses, and the get/setMillis need to be abstract. The object stream stuff also needs to move to the subclasses. There's one little issue: These changes break compatibility for anyone that is extending BaseDateTime. Although this is an implementation package, and so no one _should_ be extending it, is anyone out there actually doing this? |
From: Stephen C. <sco...@jo...> - 2012-11-27 13:20:24
|
Javadoc clarified. Its not a bug as the printer and parser interfaces represent just how the print/parse is to occur, not the formatter-based controls, such as locale/time-zone. thanks Stephen On 17 October 2012 19:45, John Jenkins <jo...@ce...> wrote: > Thank you. May I suggest that the documentation for the DateTimeFormatterBuilder.append(DateTimePrinter, DateTimeParser[]) be appended with something to the effect of: > > "If any of the parsers contain a overriding time zone, that zone will be ignored in the resulting DateTimeFormatter. A DateTimeFormatter has a single overriding time zone, and the parsers provided here will have no bearing on that value." > > Even writing that, it feels like a bug, but I am not sure. > > In case anyone else comes across this and wants a working solution, I have attached the source that I am going to use. Optimally, I would create IsoW3cDateTimeFormat and IsoW3cDateTimeFormatter classes, but I don't have the time to invest in that right now. > > Thanks again, > > John > > > > > On Oct 16, 2012, at 2:06 PM, Stephen Colebourne <sco...@jo...> wrote: > >> Ultimately, there is only one parser being run, the outer one. The >> other parts simply help build up the outer parser. So, I suspect that >> what you want may not be possible. >> >> For the other parsers, you probably want to call withOffsetParsed(), >> as that will correctly read in and create zone information based on >> the parsed offset. Even so, I'm not convinced that you could parse all >> those formats in a single bound. >> >> Of course, you do have the ability to take more control and implement >> DateTimeParser yourself, but that seems a little bit of overkill. >> >> Stephen >> >> >> On 16 October 2012 17:35, John Jenkins <jo...@ce...> wrote: >>> Sorry to pry, but I think you may have missed my follow-up question. >>> >>> With your solution, the resulting DateTime object loses its time zone, but >>> the last 3 parsers attempt to preserve that information. I only need it to >>> default to UTC for the first three. Is there a way to modify only those >>> parsers, not the entire DateTimeFormatter, to have them default to UTC >>> instead of the local time? >>> >>> Thank you, >>> >>> John >>> >>> On Oct 11, 2012, at 9:37 AM, John Jenkins <jo...@ce...> wrote: >>> >>> Thank you. That line was not intended to be sent, but your solution will >>> work for me for the time being. >>> >>> However, the larger problem that I am going to face with this solution is >>> that the timezone information is lost. If they give me one of the first >>> three formats then the timezone defaults to UTC, which is what your fix >>> does. But, if they give me any of the last three timezones, I need to >>> preserve the timezone. That is why I was trying to add the "withZoneUTC()" >>> to the individual parsers and not the larger formatter. >>> >>> Then, my formatter would probably be: >>> DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); >>> builder.append(ISODateTimeFormat.dateTime().getPrinter(), parsers); >>> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); >>> >>> Thank you, >>> >>> John >>> >>> On Oct 11, 2012, at 3:25 AM, Stephen Colebourne <sco...@jo...> >>> wrote: >>> >>> You wrote: >>> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); >>> ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC(); >>> >>> The second line has no effect, because the formatter is immutable, and >>> you do not assign back the variable. >>> >>> This will work: >>> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC(); >>> >>> Your code is also similar to >>> http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29 >>> >>> Stephen >>> >>> >>> On 11 October 2012 00:04, John Jenkins <jo...@ce...> wrote: >>> >>> I apologize if this has been answered / justified elsewhere, but I could not >>> find it. >>> >>> I am creating a parser based on the ISO year-month-day parser. I want to set >>> the default timezone of the returned object to UTC, but it is instead >>> defaulting to my local timezone. The code looks like this: >>> >>> ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); >>> >>> The only pseduo-reasoning I have found was in the documentation: >>> >>> This will parse the text fully according to the formatter, using the UTC >>> zone. Once parsed, only the local date-time will be used. This means that >>> any parsed time-zone or offset field is completely ignored. It also means >>> that the zone and offset-parsed settings are ignored. >>> >>> What I expect to happen is that the string "2012-08-15" be decoded to a time >>> that represents midnight on August 15th, 2012 at UTC. Instead, I get that >>> date and time but at my local timezone, e.g. >>> "2012-08-15T00:00:00.000-07:00". >>> >>> I am just curious why this is. A colleague and I discussed it. The answer he >>> came up with is, because only a date is supplied, the time zone doesn't >>> matter. However, I would argue that, at 23:00 PM on December 31 it would >>> very much matter. The year, month, and day can all vary depending where you >>> are in the world, so all three values may be different. But, they do >>> represent the same moment in time. This can only be determined if the >>> timezone is also included. >>> >>> I attached the complete source, but I don't know if that will be preserved. >>> >>> Thank you, >>> >>> John >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Joda-interest mailing list >>> Jod...@li... >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Joda-interest mailing list >>> Jod...@li... >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ >>> Joda-interest mailing list >>> Jod...@li... >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Joda-interest mailing list >>> Jod...@li... >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_sfd2d_oct >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Stephen C. <sco...@jo...> - 2012-11-27 12:46:22
|
Fixed, although you had an off-by-one error in your fix ;-) Stephen On 20 November 2012 22:38, Stephen Colebourne <sco...@jo...> wrote: > On 20 November 2012 21:53, Thorvald Natvig <tho...@me...> wrote: >> Due to a really wrong date ending up in our system, I found a small >> discrepancy in LocalDate.fromCalendarFields. >> >> calendar.get(Calendar.YEAR) will return +3 for both 3 AD and 3 BC, which >> means they are both treated equally by fromCalendarFields. >> >> I added a local workaround, which was simply: >> >> return new LocalDate( >> calendar.get(Calendar.YEAR) * >> (calendar.get(Calendar.ERA) == GregorianCalendar.AD ? 1 : -1), >> calendar.get(Calendar.MONTH) + 1, >> calendar.get(Calendar.DAY_OF_MONTH)); >> >> .. which seems to have fixed the problem for me. >> >> Any chance of this being fixed in the next release? > > Bad coding on my part. Sorry. A GitHub pull request would pretty much > guarantee it being in the next release. > thanks > Stephen |
From: Stephen C. <sco...@jo...> - 2012-11-22 11:28:08
|
I can see how this might be useful. It is essentially the Duration between the start of two dates. There are complications that this code doesn't handle. Firstly, DateMidnight is effectively deprecated as it doesn't handle the case where 00:00 to 01:00 does not exist due to DST. There are definitely other cases than 23, 24 and 35 hours days. Although I've never seen it, it would be possible for DST to skip 23:30 to 00:30, or repeat those times. That would haveto be handled as well. Finally, a Period is probably the right result type, once the data is calculated. So, yes poentially useful, but hard to implement (harder than the code below ;-) thanks Stephen On 22 November 2012 10:41, Joda forum Bill Comer <bil...@be...> wrote: > Hi all, > > I was recently had a requirement where I needed to determine if a day was a > LONG, SHORT or NORMAL day, > & I wondered if it would be a useful addition to Joda-Time. > > I have written it up here - > http://billcomer.blogspot.co.uk/2012/11/clock-changing-is-this-long-short-or.html > > But here it is as well. > > public enum ClockChangeInfo { > > LONG_DAY(90000000, 25), SHORT_DAY(82800000, 23), NORMAL_DAY(86400000, 24), > INDETERMINATE(0, 0); > > private int mMsecs; > private int mHrs; > private static final Map<Integer, ClockChangeInfo> MSEC = new > HashMap<Integer, ClockChangeInfo>(); > > static { > for (ClockChangeInfo cci : values()) { > MSEC.put(new Integer(cci.mMsecs), cci); > } > } > > ClockChangeInfo(int aMsecs, int aHrs) { > mMsecs = aMsecs; > mHrs = aHrs; > } > > public int getHrs(ClockChangeInfo aCci) { > return aCci.mHrs; > } > > public static ClockChangeInfo getDayType(DateMidnight dateToCheck) { > DateMidnight nextDay = dateToCheck.plusDays(1); > > //this is a safe convert as it is only for day(n) - day(n-1) > Integer millis = (int)(nextDay.getMillis() - dateToCheck.getMillis()); > ClockChangeInfo cci = MSEC.get(millis); > if (cci == null) { > return INDETERMINATE; > } > return cci; > } > } > > public class ClockChangeUtil { > > public static ClockChangeInfo getDayType(DateMidnight dateToCheck) { > return ClockChangeInfo.getDayType((dateToCheck)); > } > > public static int getNumHoursInDay(DateMidnight dateToCheck) { > ClockChangeInfo dayType = ClockChangeUtil.getDayType(dateToCheck); > return dayType.getHrs(dayType); > } > > public static int getNumHalfHoursINMonthSoFar(DateMidnight dateToCheck) { > int numHours = 0; > int day = dateToCheck.getDayOfMonth(); > > if (day == 1) { > return 0; > } > > DateMidnight dm = dateToCheck.minusDays(1); > > do { > numHours += getNumHoursInDay(dm); > > dm = dm.minusDays(1); > day--; > } while (day > 1); > > return numHours * 2; > } > } > > > & some tests > > public class ClockChangeUtilUnitTest > { > > @Test > public void test_isLongDay() throws Exception > { > DateMidnight dm28 = new DateMidnight(2011, 10, 28); > DateMidnight dm29 = new DateMidnight(2011, 10, 29); > DateMidnight dm30 = new DateMidnight(2011, 10, 30); > DateMidnight dm31 = new DateMidnight(2011, 10, 31); > > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm28)); > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm29)); > assertEquals(ClockChangeInfo.LONG_DAY, > ClockChangeUtil.getDayType(dm30)); > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm31)); > } > > > @Test > public void test_isShortDay() throws Exception > { > DateMidnight dm26 = new DateMidnight(2011, 3, 26); > DateMidnight dm27 = new DateMidnight(2011, 3, 27); > DateMidnight dm28 = new DateMidnight(2011, 3, 28); > DateMidnight dm29 = new DateMidnight(2011, 3, 29); > > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm26)); > assertEquals(ClockChangeInfo.SHORT_DAY, > ClockChangeUtil.getDayType(dm27)); > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm28)); > assertEquals(ClockChangeInfo.NORMAL_DAY, > ClockChangeUtil.getDayType(dm29)); > } > > > @Test > public void testClockChange() throws Exception > { > long millisInANormalDay = 24 * 60 * 60 * 1000; > long millisInALongDay = 25 * 60 * 60 * 1000; > > DateMidnight dm28 = new DateMidnight(2011, 10, 28); > DateMidnight dm29 = new DateMidnight(2011, 10, 29); > DateMidnight dm30 = new DateMidnight(2011, 10, 30); > DateMidnight dm31 = new DateMidnight(2011, 10, 31); > > assertEquals(millisInANormalDay, dm29.getMillis() - dm28.getMillis()); > assertEquals(millisInANormalDay, dm30.getMillis() - dm29.getMillis()); > assertEquals(millisInALongDay, dm31.getMillis() - dm30.getMillis()); > > > DateTime dt28 = new DateTime(dm28); > DateTime dt29 = new DateTime(dm29); > DateTime dt30 = new DateTime(dm30); > DateTime dt31 = new DateTime(dm31); > > assertEquals(millisInANormalDay, dt29.getMillis() - dt28.getMillis()); > assertEquals(millisInANormalDay, dt30.getMillis() - dt29.getMillis()); > assertEquals(millisInALongDay, dt31.getMillis() - dt30.getMillis()); > > assertTrue(dt28.getZone().equals(dt29.getZone())); > assertTrue(dt28.getZone().equals(dt30.getZone())); > assertTrue(dt28.getZone().equals(dt31.getZone())); > } > > @Test > public void test_getNumHoursInDay() throws Exception > { > > DateMidnight dm26 = new DateMidnight(2011, 3, 26); > DateMidnight dm27 = new DateMidnight(2011, 3, 27); > DateMidnight dm28 = new DateMidnight(2011, 3, 28); > DateMidnight dm29 = new DateMidnight(2011, 3, 29); > > assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm26)); > assertEquals(23, ClockChangeUtil.getNumHoursInDay(dm27)); > assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm28)); > assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm29)); > } > > } > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Joda f. B. C. <bil...@be...> - 2012-11-22 10:41:10
|
Hi all, I was recently had a requirement where I needed to determine if a day was a LONG, SHORT or NORMAL day, & I wondered if it would be a useful addition to Joda-Time. I have written it up here - http://billcomer.blogspot.co.uk/2012/11/clock-changing-is-this-long-short-or.html But here it is as well. public enum ClockChangeInfo { LONG_DAY(90000000, 25), SHORT_DAY(82800000, 23), NORMAL_DAY(86400000, 24), INDETERMINATE(0, 0); private int mMsecs; private int mHrs; private static final Map<Integer, ClockChangeInfo> MSEC = new HashMap<Integer, ClockChangeInfo>(); static { for (ClockChangeInfo cci : values()) { MSEC.put(new Integer(cci.mMsecs), cci); } } ClockChangeInfo(int aMsecs, int aHrs) { mMsecs = aMsecs; mHrs = aHrs; } public int getHrs(ClockChangeInfo aCci) { return aCci.mHrs; } public static ClockChangeInfo getDayType(DateMidnight dateToCheck) { DateMidnight nextDay = dateToCheck.plusDays(1); //this is a safe convert as it is only for day(n) - day(n-1) Integer millis = (int)(nextDay.getMillis() - dateToCheck.getMillis()); ClockChangeInfo cci = MSEC.get(millis); if (cci == null) { return INDETERMINATE; } return cci; } } public class ClockChangeUtil { public static ClockChangeInfo getDayType(DateMidnight dateToCheck) { return ClockChangeInfo.getDayType((dateToCheck)); } public static int getNumHoursInDay(DateMidnight dateToCheck) { ClockChangeInfo dayType = ClockChangeUtil.getDayType(dateToCheck); return dayType.getHrs(dayType); } public static int getNumHalfHoursINMonthSoFar(DateMidnight dateToCheck) { int numHours = 0; int day = dateToCheck.getDayOfMonth(); if (day == 1) { return 0; } DateMidnight dm = dateToCheck.minusDays(1); do { numHours += getNumHoursInDay(dm); dm = dm.minusDays(1); day--; } while (day > 1); return numHours * 2; } } & some tests public class ClockChangeUtilUnitTest { @Test public void test_isLongDay() throws Exception { DateMidnight dm28 = new DateMidnight(2011, 10, 28); DateMidnight dm29 = new DateMidnight(2011, 10, 29); DateMidnight dm30 = new DateMidnight(2011, 10, 30); DateMidnight dm31 = new DateMidnight(2011, 10, 31); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm28)); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm29)); assertEquals(ClockChangeInfo.LONG_DAY, ClockChangeUtil.getDayType(dm30)); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm31)); } @Test public void test_isShortDay() throws Exception { DateMidnight dm26 = new DateMidnight(2011, 3, 26); DateMidnight dm27 = new DateMidnight(2011, 3, 27); DateMidnight dm28 = new DateMidnight(2011, 3, 28); DateMidnight dm29 = new DateMidnight(2011, 3, 29); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm26)); assertEquals(ClockChangeInfo.SHORT_DAY, ClockChangeUtil.getDayType(dm27)); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm28)); assertEquals(ClockChangeInfo.NORMAL_DAY, ClockChangeUtil.getDayType(dm29)); } @Test public void testClockChange() throws Exception { long millisInANormalDay = 24 * 60 * 60 * 1000; long millisInALongDay = 25 * 60 * 60 * 1000; DateMidnight dm28 = new DateMidnight(2011, 10, 28); DateMidnight dm29 = new DateMidnight(2011, 10, 29); DateMidnight dm30 = new DateMidnight(2011, 10, 30); DateMidnight dm31 = new DateMidnight(2011, 10, 31); assertEquals(millisInANormalDay, dm29.getMillis() - dm28.getMillis()); assertEquals(millisInANormalDay, dm30.getMillis() - dm29.getMillis()); assertEquals(millisInALongDay, dm31.getMillis() - dm30.getMillis()); DateTime dt28 = new DateTime(dm28); DateTime dt29 = new DateTime(dm29); DateTime dt30 = new DateTime(dm30); DateTime dt31 = new DateTime(dm31); assertEquals(millisInANormalDay, dt29.getMillis() - dt28.getMillis()); assertEquals(millisInANormalDay, dt30.getMillis() - dt29.getMillis()); assertEquals(millisInALongDay, dt31.getMillis() - dt30.getMillis()); assertTrue(dt28.getZone().equals(dt29.getZone())); assertTrue(dt28.getZone().equals(dt30.getZone())); assertTrue(dt28.getZone().equals(dt31.getZone())); } @Test public void test_getNumHoursInDay() throws Exception { DateMidnight dm26 = new DateMidnight(2011, 3, 26); DateMidnight dm27 = new DateMidnight(2011, 3, 27); DateMidnight dm28 = new DateMidnight(2011, 3, 28); DateMidnight dm29 = new DateMidnight(2011, 3, 29); assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm26)); assertEquals(23, ClockChangeUtil.getNumHoursInDay(dm27)); assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm28)); assertEquals(24, ClockChangeUtil.getNumHoursInDay(dm29)); } } |
From: Stephen C. <sco...@jo...> - 2012-11-20 22:38:29
|
On 20 November 2012 21:53, Thorvald Natvig <tho...@me...> wrote: > Due to a really wrong date ending up in our system, I found a small > discrepancy in LocalDate.fromCalendarFields. > > calendar.get(Calendar.YEAR) will return +3 for both 3 AD and 3 BC, which > means they are both treated equally by fromCalendarFields. > > I added a local workaround, which was simply: > > return new LocalDate( > calendar.get(Calendar.YEAR) * > (calendar.get(Calendar.ERA) == GregorianCalendar.AD ? 1 : -1), > calendar.get(Calendar.MONTH) + 1, > calendar.get(Calendar.DAY_OF_MONTH)); > > .. which seems to have fixed the problem for me. > > Any chance of this being fixed in the next release? Bad coding on my part. Sorry. A GitHub pull request would pretty much guarantee it being in the next release. thanks Stephen |
From: Thorvald N. <tho...@me...> - 2012-11-20 22:15:42
|
Hi, Due to a really wrong date ending up in our system, I found a small discrepancy in LocalDate.fromCalendarFields. calendar.get(Calendar.YEAR) will return +3 for both 3 AD and 3 BC, which means they are both treated equally by fromCalendarFields. I added a local workaround, which was simply: return new LocalDate( calendar.get(Calendar.YEAR) * (calendar.get(Calendar.ERA) == GregorianCalendar.AD ? 1 : -1), calendar.get(Calendar.MONTH) + 1, calendar.get(Calendar.DAY_OF_MONTH)); .. which seems to have fixed the problem for me. Any chance of this being fixed in the next release? Regards, Thorvald |
From: datakey <use...@gm...> - 2012-11-14 12:42:04
|
Is this "feature" (only optional millis) tested already? Or should I use the code from the user? Thanks! -- View this message in context: http://joda-interest.219941.n2.nabble.com/Parsing-xsd-dateTime-optional-millis-tp7211557p7572479.html Sent from the Joda-Interest mailing list archive at Nabble.com. |
From: <met...@da...> - 2012-11-01 16:25:38
|
Hi all! I'm using JodaTime 2.1 on Android (SDK 20, API 16) and stumbled upon a weird error: DateTimeZone.forID("+01:00") returns a DateTimeZone with the internal ID "UTC", and not, as expected, "+01:00". I saw that this is (of course) tested and that this particular case seems to properly work on a Desktop Java integration platform, so I pretty much guess that it is an Android issue. For now I wrote some code to parse DateTimeZone ids myself, i.e. String id = "+01:00"; DateTimeZone zone; if (id.matches("(\\+|\\-)\\d{2}:\\d{2}")) { String offsetParts[] = id.split(":"); zone = DateTimeZone.forOffsetHoursMinutes( Integer.parseInt(offsetParts[0].replace("+", "")), Integer.parseInt(offsetParts[1])); } else { Zone = DateTimeZone.forID(id); } and this works, but I'm not confident anymore if there aren't other subtle errors in the library unless I know where this problem really originates from. Any idea how to debug this issue? Thanks, Thomas. |
From: Stephen C. <sco...@jo...> - 2012-10-30 08:46:12
|
On 28 October 2012 20:58, Marcel Stör <ma...@fr...> wrote: > Today after DST shift one of our unit tests failed. The method under > test no longer returned proper values. > > The method takes a javax.xml.datatype.XMLGregorianCalendar, converts it > to DateTime, and sets the time to last milli of the day i.e. > 23:59:59.999. When I checked the final value it was > 2012-10-28T23:59:59.999+02:00 which is correct apart from the +2 > (instead of +1) time zone. > > When I checked the chronology of the DateTime object it said > "GregorianChronology[+02:00]". If I manually set the chronology by > invoking .withChronology(GregorianChronology.getInstance()) I get > "GregorianChronology[Europe/Berlin]" and the code works as intended. > > This is the code: > new DateTime(xmlCal.toGregorianCalendar()).plusDays(1).minusMillis(1); I don't think this is anything to do with XMLGregorianCalendar (because you convert to GregorianCalendar first), although I could be wrong. The conversion from Calendar to DateTime occurs in the Joda-Time class CalendarConverter. That class uses the time-zone of the Calendar object to set the time-zone in the DateTime object. If the time-zone conversion fails, the default time-zone of the JVM is used. Somewhere is that conversion, the time-zone isn't doing what it did before. I'd recommend you debug against a source download (as I don't have enough information to tell you where the problem is). Stephen |
From: Marcel S. <ma...@fr...> - 2012-10-28 20:58:17
|
Today after DST shift one of our unit tests failed. The method under test no longer returned proper values. The method takes a javax.xml.datatype.XMLGregorianCalendar, converts it to DateTime, and sets the time to last milli of the day i.e. 23:59:59.999. When I checked the final value it was 2012-10-28T23:59:59.999+02:00 which is correct apart from the +2 (instead of +1) time zone. When I checked the chronology of the DateTime object it said "GregorianChronology[+02:00]". If I manually set the chronology by invoking .withChronology(GregorianChronology.getInstance()) I get "GregorianChronology[Europe/Berlin]" and the code works as intended. This is the code: new DateTime(xmlCal.toGregorianCalendar()).plusDays(1).minusMillis(1); Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O< ascii ribbon campaign - stop html mail - www.asciiribbon.org |
From: John J. <jo...@ce...> - 2012-10-18 21:27:13
|
I am not sure if this is a bug or if I am incorrectly implementing the parseInto() function. I cannot chain the parsers and am not sure why. In ISOW3CDateTimeParser's parseInto() function, if the first three parsers fail, I must reset the bucket in order to check the last three. However, the entirety of the third pattern is the same as the beginning of the forth pattern, so I am not sure why I need to reset. If this is a bug, then the ISOW3CDateTimeParser and the any() function could be removed. The any() function is a simple wrapper around the ISOW3CDateTimeParser, which is necessary because the parseInto() function is failing. Also, since the W3C standard is pretty common, I would be thrilled if this were integrated into the code base, but I don't expect it. If so, I can flesh out all of the tests. Thank you, John |
From: John J. <jo...@ce...> - 2012-10-17 18:46:07
|
Thank you. May I suggest that the documentation for the DateTimeFormatterBuilder.append(DateTimePrinter, DateTimeParser[]) be appended with something to the effect of: "If any of the parsers contain a overriding time zone, that zone will be ignored in the resulting DateTimeFormatter. A DateTimeFormatter has a single overriding time zone, and the parsers provided here will have no bearing on that value." Even writing that, it feels like a bug, but I am not sure. In case anyone else comes across this and wants a working solution, I have attached the source that I am going to use. Optimally, I would create IsoW3cDateTimeFormat and IsoW3cDateTimeFormatter classes, but I don't have the time to invest in that right now. Thanks again, John |
From: Stephen C. <sco...@jo...> - 2012-10-16 21:06:32
|
Ultimately, there is only one parser being run, the outer one. The other parts simply help build up the outer parser. So, I suspect that what you want may not be possible. For the other parsers, you probably want to call withOffsetParsed(), as that will correctly read in and create zone information based on the parsed offset. Even so, I'm not convinced that you could parse all those formats in a single bound. Of course, you do have the ability to take more control and implement DateTimeParser yourself, but that seems a little bit of overkill. Stephen On 16 October 2012 17:35, John Jenkins <jo...@ce...> wrote: > Sorry to pry, but I think you may have missed my follow-up question. > > With your solution, the resulting DateTime object loses its time zone, but > the last 3 parsers attempt to preserve that information. I only need it to > default to UTC for the first three. Is there a way to modify only those > parsers, not the entire DateTimeFormatter, to have them default to UTC > instead of the local time? > > Thank you, > > John > > On Oct 11, 2012, at 9:37 AM, John Jenkins <jo...@ce...> wrote: > > Thank you. That line was not intended to be sent, but your solution will > work for me for the time being. > > However, the larger problem that I am going to face with this solution is > that the timezone information is lost. If they give me one of the first > three formats then the timezone defaults to UTC, which is what your fix > does. But, if they give me any of the last three timezones, I need to > preserve the timezone. That is why I was trying to add the "withZoneUTC()" > to the individual parsers and not the larger formatter. > > Then, my formatter would probably be: > DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); > builder.append(ISODateTimeFormat.dateTime().getPrinter(), parsers); > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); > > Thank you, > > John > > On Oct 11, 2012, at 3:25 AM, Stephen Colebourne <sco...@jo...> > wrote: > > You wrote: > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); > ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC(); > > The second line has no effect, because the formatter is immutable, and > you do not assign back the variable. > > This will work: > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC(); > > Your code is also similar to > http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29 > > Stephen > > > On 11 October 2012 00:04, John Jenkins <jo...@ce...> wrote: > > I apologize if this has been answered / justified elsewhere, but I could not > find it. > > I am creating a parser based on the ISO year-month-day parser. I want to set > the default timezone of the returned object to UTC, but it is instead > defaulting to my local timezone. The code looks like this: > > ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); > > The only pseduo-reasoning I have found was in the documentation: > > This will parse the text fully according to the formatter, using the UTC > zone. Once parsed, only the local date-time will be used. This means that > any parsed time-zone or offset field is completely ignored. It also means > that the zone and offset-parsed settings are ignored. > > What I expect to happen is that the string "2012-08-15" be decoded to a time > that represents midnight on August 15th, 2012 at UTC. Instead, I get that > date and time but at my local timezone, e.g. > "2012-08-15T00:00:00.000-07:00". > > I am just curious why this is. A colleague and I discussed it. The answer he > came up with is, because only a date is supplied, the time zone doesn't > matter. However, I would argue that, at 23:00 PM on December 31 it would > very much matter. The year, month, and day can all vary depending where you > are in the world, so all three values may be different. But, they do > represent the same moment in time. This can only be determined if the > timezone is also included. > > I attached the complete source, but I don't know if that will be preserved. > > Thank you, > > John > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: John J. <jo...@ce...> - 2012-10-16 16:35:22
|
Sorry to pry, but I think you may have missed my follow-up question. With your solution, the resulting DateTime object loses its time zone, but the last 3 parsers attempt to preserve that information. I only need it to default to UTC for the first three. Is there a way to modify only those parsers, not the entire DateTimeFormatter, to have them default to UTC instead of the local time? Thank you, John On Oct 11, 2012, at 9:37 AM, John Jenkins <jo...@ce...> wrote: > Thank you. That line was not intended to be sent, but your solution will work for me for the time being. > > However, the larger problem that I am going to face with this solution is that the timezone information is lost. If they give me one of the first three formats then the timezone defaults to UTC, which is what your fix does. But, if they give me any of the last three timezones, I need to preserve the timezone. That is why I was trying to add the "withZoneUTC()" to the individual parsers and not the larger formatter. > > Then, my formatter would probably be: > DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); > builder.append(ISODateTimeFormat.dateTime().getPrinter(), parsers); > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); > > Thank you, > > John > > On Oct 11, 2012, at 3:25 AM, Stephen Colebourne <sco...@jo...> wrote: > >> You wrote: >> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); >> ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC(); >> >> The second line has no effect, because the formatter is immutable, and >> you do not assign back the variable. >> >> This will work: >> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC(); >> >> Your code is also similar to >> http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29 >> >> Stephen >> >> >> On 11 October 2012 00:04, John Jenkins <jo...@ce...> wrote: >>> I apologize if this has been answered / justified elsewhere, but I could not >>> find it. >>> >>> I am creating a parser based on the ISO year-month-day parser. I want to set >>> the default timezone of the returned object to UTC, but it is instead >>> defaulting to my local timezone. The code looks like this: >>> >>> ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); >>> >>> The only pseduo-reasoning I have found was in the documentation: >>> >>> This will parse the text fully according to the formatter, using the UTC >>> zone. Once parsed, only the local date-time will be used. This means that >>> any parsed time-zone or offset field is completely ignored. It also means >>> that the zone and offset-parsed settings are ignored. >>> >>> What I expect to happen is that the string "2012-08-15" be decoded to a time >>> that represents midnight on August 15th, 2012 at UTC. Instead, I get that >>> date and time but at my local timezone, e.g. >>> "2012-08-15T00:00:00.000-07:00". >>> >>> I am just curious why this is. A colleague and I discussed it. The answer he >>> came up with is, because only a date is supplied, the time zone doesn't >>> matter. However, I would argue that, at 23:00 PM on December 31 it would >>> very much matter. The year, month, and day can all vary depending where you >>> are in the world, so all three values may be different. But, they do >>> represent the same moment in time. This can only be determined if the >>> timezone is also included. >>> >>> I attached the complete source, but I don't know if that will be preserved. >>> >>> Thank you, >>> >>> John >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Joda-interest mailing list >>> Jod...@li... >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: John J. <jo...@ce...> - 2012-10-11 16:37:11
|
Thank you. That line was not intended to be sent, but your solution will work for me for the time being. However, the larger problem that I am going to face with this solution is that the timezone information is lost. If they give me one of the first three formats then the timezone defaults to UTC, which is what your fix does. But, if they give me any of the last three timezones, I need to preserve the timezone. That is why I was trying to add the "withZoneUTC()" to the individual parsers and not the larger formatter. Then, my formatter would probably be: DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); builder.append(ISODateTimeFormat.dateTime().getPrinter(), parsers); ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); Thank you, John On Oct 11, 2012, at 3:25 AM, Stephen Colebourne <sco...@jo...> wrote: > You wrote: > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); > ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC(); > > The second line has no effect, because the formatter is immutable, and > you do not assign back the variable. > > This will work: > ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC(); > > Your code is also similar to > http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29 > > Stephen > > > On 11 October 2012 00:04, John Jenkins <jo...@ce...> wrote: >> I apologize if this has been answered / justified elsewhere, but I could not >> find it. >> >> I am creating a parser based on the ISO year-month-day parser. I want to set >> the default timezone of the returned object to UTC, but it is instead >> defaulting to my local timezone. The code looks like this: >> >> ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); >> >> The only pseduo-reasoning I have found was in the documentation: >> >> This will parse the text fully according to the formatter, using the UTC >> zone. Once parsed, only the local date-time will be used. This means that >> any parsed time-zone or offset field is completely ignored. It also means >> that the zone and offset-parsed settings are ignored. >> >> What I expect to happen is that the string "2012-08-15" be decoded to a time >> that represents midnight on August 15th, 2012 at UTC. Instead, I get that >> date and time but at my local timezone, e.g. >> "2012-08-15T00:00:00.000-07:00". >> >> I am just curious why this is. A colleague and I discussed it. The answer he >> came up with is, because only a date is supplied, the time zone doesn't >> matter. However, I would argue that, at 23:00 PM on December 31 it would >> very much matter. The year, month, and day can all vary depending where you >> are in the world, so all three values may be different. But, they do >> represent the same moment in time. This can only be determined if the >> timezone is also included. >> >> I attached the complete source, but I don't know if that will be preserved. >> >> Thank you, >> >> John >> >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: Stephen C. <sco...@jo...> - 2012-10-11 10:25:48
|
You wrote: ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter(); ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC(); The second line has no effect, because the formatter is immutable, and you do not assign back the variable. This will work: ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC(); Your code is also similar to http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29 Stephen On 11 October 2012 00:04, John Jenkins <jo...@ce...> wrote: > I apologize if this has been answered / justified elsewhere, but I could not > find it. > > I am creating a parser based on the ISO year-month-day parser. I want to set > the default timezone of the returned object to UTC, but it is instead > defaulting to my local timezone. The code looks like this: > > ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); > > The only pseduo-reasoning I have found was in the documentation: > > This will parse the text fully according to the formatter, using the UTC > zone. Once parsed, only the local date-time will be used. This means that > any parsed time-zone or offset field is completely ignored. It also means > that the zone and offset-parsed settings are ignored. > > What I expect to happen is that the string "2012-08-15" be decoded to a time > that represents midnight on August 15th, 2012 at UTC. Instead, I get that > date and time but at my local timezone, e.g. > "2012-08-15T00:00:00.000-07:00". > > I am just curious why this is. A colleague and I discussed it. The answer he > came up with is, because only a date is supplied, the time zone doesn't > matter. However, I would argue that, at 23:00 PM on December 31 it would > very much matter. The year, month, and day can all vary depending where you > are in the world, so all three values may be different. But, they do > represent the same moment in time. This can only be determined if the > timezone is also included. > > I attached the complete source, but I don't know if that will be preserved. > > Thank you, > > John > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: John J. <jo...@ce...> - 2012-10-10 23:22:55
|
I apologize if this has been answered / justified elsewhere, but I could not find it. I am creating a parser based on the ISO year-month-day parser. I want to set the default timezone of the returned object to UTC, but it is instead defaulting to my local timezone. The code looks like this: ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser(); The only pseduo-reasoning I have found was in the documentation: This will parse the text fully according to the formatter, using the UTC zone. Once parsed, only the local date-time will be used. This means that any parsed time-zone or offset field is completely ignored. It also means that the zone and offset-parsed settings are ignored. What I expect to happen is that the string "2012-08-15" be decoded to a time that represents midnight on August 15th, 2012 at UTC. Instead, I get that date and time but at my local timezone, e.g. "2012-08-15T00:00:00.000-07:00". I am just curious why this is. A colleague and I discussed it. The answer he came up with is, because only a date is supplied, the time zone doesn't matter. However, I would argue that, at 23:00 PM on December 31 it would very much matter. The year, month, and day can all vary depending where you are in the world, so all three values may be different. But, they do represent the same moment in time. This can only be determined if the timezone is also included. I attached the complete source, but I don't know if that will be preserved. Thank you, John |
From: Stephen C. <sco...@jo...> - 2012-10-08 10:06:23
|
There is no special behaviour in Joda-Time to support this. That just means that its up to you to come up with a good algorithm based on what Joda-Time does provide. Stephen On 6 October 2012 20:39, Michael Crawford <da...@gm...> wrote: > Hi all, > > I was wondering if there is a way to check if a day of the week exists > between two datetime's > > For instance say I have thursday oct 4th 2012 and saturday oct 6th 2012 > > I want to see if the interval between these 2 dates encompasses a friday. > > I saw how to check if a certain hour of the day exists but not a day of the > week. > > Or maybe I am going about this wrong. All ideas welcome > > Thanks, > Mike > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Michael C. <da...@gm...> - 2012-10-06 19:39:55
|
Hi all, I was wondering if there is a way to check if a day of the week exists between two datetime's For instance say I have thursday oct 4th 2012 and saturday oct 6th 2012 I want to see if the interval between these 2 dates encompasses a friday. I saw how to check if a certain hour of the day exists but not a day of the week. Or maybe I am going about this wrong. All ideas welcome Thanks, Mike |
From: Kasper L. <kl...@co...> - 2012-09-27 17:27:50
|
----- Original Message ----- > Committed in > https://github.com/JodaOrg/joda-time/commit/136667ccf66c62866dc99c7967cf8491804a54be Great. Nice to know I could help in small ways. > with change from "date" to "dage" for plural days. That is a correct change. Embarrassing that I missed that. /Kasper |
From: Stephen C. <sco...@jo...> - 2012-09-27 13:47:12
|
Committed in https://github.com/JodaOrg/joda-time/commit/136667ccf66c62866dc99c7967cf8491804a54be with change from "date" to "dage" for plural days. Stephen On 27 September 2012 12:50, Kasper Laudrup <kl...@co...> wrote: > Hi there, > > I have been using the PeriodFormatter class for formatting some output, but needed the language to be in Danish. In order to do that I have created a Danish messages.properties file. I have attached it to this post in hope someone else might find it useful or even add it to the repository. > > -- > Venlig hilsen/Kind regards, > > Kasper Laudrup > Developer > Code3 ApS > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Kasper L. <kl...@co...> - 2012-09-27 12:08:38
|
Hi there, I have been using the PeriodFormatter class for formatting some output, but needed the language to be in Danish. In order to do that I have created a Danish messages.properties file. I have attached it to this post in hope someone else might find it useful or even add it to the repository. -- Venlig hilsen/Kind regards, Kasper Laudrup Developer Code3 ApS |