SimpleDateFormat parse

Tengo un problema con SimpleDateFormat:

Error:

Fecha imposible de extraer: "Jue, 09 Nov 2017 16:17:42 GMT"

Código:

DF_SERVER_FORMAT="EEE, dd MMM yyyy HH:mm:ss'Z'" .... var formater=SimpleDateFormat(DF_SERVER_FORMAT) formater.parse(source) 

según la documentation de SimpleDateFormat , Z (en mayúscula) es para una zona horaria RFC 822 , por ejemplo, -0800

para una zona horaria general use z .

Esto debería funcionar:

DF_SERVER_FORMAT="EEE, dd MMM yyyy HH:mm:ss z"

Pruebe "EEE, d MMM yyyy HH:mm:ss z" este patrón funciona para mí.

Puede tratar de formatear una date utilizando su patrón, para ver la diferencia y luego corregir su patrón en consecuencia. Esto es lo que hice en J2SE:

 SimpleDateFormat df = new SimpleDateFormat("EEE dd MMM yyyy HH:mm:ss'Z'"); System.out.println(df.format(new Date())); 

Esto está produciendo:

Jue 09 Nov 2017 17: 49: 07Z

Pero, cuando usé el patrón " EEE, dd MMM aaaa HH: mm: ss z ", produjo el resultado esperado:

Jue, 09 Nov 2017 17:51:09 CET

Para cualquiera que esté bien con una dependencia externa (temporalmente) o que esté usando Java 8 o posterior, quería contribuir con la respuesta moderna. Porque considero que SimpleDateFormat obsoleto hace mucho time.

La moderna API de date y hora de Java es generalmente mucho mejor para trabajar. Además, su cadena está en formatting RFC 1123, y la API moderna viene con un formateador para este formatting. Así que no es necesario que construyas tu secuencia de patrones de formatting tú mismo (mi código es puro Java, confío en que adoptes a Kotlin):

  String dateString = "Thu, 09 Nov 2017 16:17:42 GMT"; OffsetDateTime dateTime = OffsetDateTime.parse(dateString, DateTimeFormatter.RFC_1123_DATE_TIME); 

Esto produce un OffsetDateTime de 2017-11-09T16:17:42Z como se esperaba.

Para usar esto en Android, obtenga ThreeTenABP , vea esta pregunta: Cómo usar ThreeTenABP en el Proyecto Android . Java 8 y versiones posteriores vienen con la API moderna incorporada. Si usa Java 6 o 7 en un dispositivo que no es Android, necesita el ThreeTen Backport .

¿Qué salió mal en tu código? Con su cadena de patrón de formatting, usted estaba pidiendo una Z literal justo después de los segundos, sin espacio entre ellos. Dado que su cadena de input no tenía una Z allí, el análisis falló (en cambio, tenía un espacio y el ID de desplazamiento GMT ). Además, su código parece ser sensible a la configuration regional: si su configuration regional pnetworkingeterminada es una donde la abreviatura del jueves no es Thu o noviembre, no noviembre, el análisis fracasará (en contraste, RFC_1123_DATE_TIME espera (y requiere) abreviaturas de día y de mes en Inglés independientemente de la configuration regional).