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 <joje...@cens.ucla.edu> 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 <scolebou...@joda.org> 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 <joje...@cens.ucla.edu> 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 <joje...@cens.ucla.edu> 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 <scolebou...@joda.org> >>> 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 <joje...@cens.ucla.edu> 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 >>> Joda-interest@lists.sourceforge.net >>> 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 >>> Joda-interest@lists.sourceforge.net >>> 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 >>> Joda-interest@lists.sourceforge.net >>> 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 >>> Joda-interest@lists.sourceforge.net >>> 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 >> Joda-interest@lists.sourceforge.net >> 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 > Joda-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/joda-interest > ------------------------------------------------------------------------------ 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 Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
