[jira] [Comment Edited] (LANG-1219) FastDateFormat doesn't respect summer daylight in localized strings

["Jarek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252028#comment-15252028 ] 

Jarek edited comment on LANG-1219 at 4/22/16 7:56 AM:
------------------------------------------------------

Just to clarify: on 26.10.2014, we have changed CEST time to CET (switched from 3:00 to 2:00), so we had double 2:00, once in CEST and once in CET.


was (Author: yossaa):
Just to clarify: on 24.10.2014, we have changed CEST time to CET (switched from 3:00 to 2:00), so we had double 2:00, once in CEST and once in CET.

> FastDateFormat doesn't respect summer daylight in localized strings
> -------------------------------------------------------------------
>
>                 Key: LANG-1219
>                 URL: https://issues.apache.org/jira/browse/LANG-1219
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.4
>            Reporter: Jarek
>              Labels: timezone
>
> FastDateFormat can't properly parse dates with daylight saving in the "z" pattern. It always returns date without daylight saving. Test case:
> {code:java}
> 		SimpleDateFormat format = new SimpleDateFormat("dd.MM.yyyy HH:mm:ss z", Locale.GERMANY);
> 		Date d1 = format.parse("26.10.2014 02:00:00 MESZ");
> 		Date d2 = format.parse("26.10.2014 02:00:00 MEZ");
> 		System.out.println(d1);
> 		System.out.println(d2);
> 		FastDateFormat formatt = FastDateFormat.getInstance("dd.MM.yyyy HH:mm:ss z", Locale.GERMANY);
> 		Date d3 = formatt.parse("26.10.2014 02:00:00 MESZ");
> 		Date d4 = formatt.parse("26.10.2014 02:00:00 MEZ");
> 		System.out.println(d3);
> 		System.out.println(d4);	
> {code}
> returns:
> SDF: Sun Oct 26 02:00:00 CEST 2014
> SDF: Sun Oct 26 02:00:00 CET 2014
> FDF: Sun Oct 26 02:00:00 CET 2014
> FDF:  Sun Oct 26 02:00:00 CET 2014
> FastDateFormat returns the same date, which is wrong.
> Bug is in the FastDateParser.TimeZoneStrategy.setCalendar:
> {code:java}
> @Override
>         void setCalendar(final FastDateParser parser, final Calendar cal, final String value) {
>             TimeZone tz;
>             if(value.charAt(0)=='+' || value.charAt(0)=='-') {
>                 tz= TimeZone.getTimeZone("GMT"+value);
>             }
>             else if(value.startsWith("GMT")) {
>                 tz= TimeZone.getTimeZone(value);
>             }
>             else {
>                 tz= tzNames.get(value);
>                 if(tz==null) {
>                     throw new IllegalArgumentException(value + " is not a supported timezone name");
>                 }
>             }
>             cal.setTimeZone(tz);
>         }
> {code}
> It's not enough to just call: cal.setTimeZone.
> If zone names in standard and daylight time are different, you have to check the name in DateFormatSymbols.getInstance(locale).getZoneStrings(); and if it's >= 3, you have to activate daylight mode.Just like SimpleDateFormat does it:
> {code:java}
> 1491            // (abbreviation) for both standard and daylight time,
> 1492            // let the time zone in the Calendar decide which one.
> 1493            if (!useSameName) {
> 1494                calendar.set(Calendar.ZONE_OFFSET, tz.getRawOffset());
> 1495                calendar.set(Calendar.DST_OFFSET,
> 1496                             j >= 3 ? tz.getDSTSavings() : 0);
> 1497            }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)