¿Cómo manejar las diferencias de la base de datos de horarios de JodaTime y Android?

Creo que las otras respuestas están perdiendo el punto. Sí, cuando persiste la información de tiempo, debe considerar cuidadosamente sus casos de uso para decidir la mejor forma de hacerlo. Pero incluso si lo hubieras hecho, el problema que plantea esta pregunta persistiría.

Considere la aplicación de reloj despertador de Android, que tiene su código fuente libremente disponible . Si observa su clase AlarmInstance , así es como se modeliza en la base de datos:

 private static final String[] QUERY_COLUMNS = { _ID, YEAR, MONTH, DAY, HOUR, MINUTES, LABEL, VIBRATE, RINGTONE, ALARM_ID, ALARM_STATE }; 

Y para saber cuándo una instancia de alarma debe disparar, llama a getAlarmTime() :

 /** * Return the time when a alarm should fire. * * @return the time */ public Calendar getAlarmTime() { Calendar calendar = Calendar.getInstance(); calendar.set(Calendar.YEAR, mYear); calendar.set(Calendar.MONTH, mMonth); calendar.set(Calendar.DAY_OF_MONTH, mDay); calendar.set(Calendar.HOUR_OF_DAY, mHour); calendar.set(Calendar.MINUTE, mMinute); calendar.set(Calendar.SECOND, 0); calendar.set(Calendar.MILLISECOND, 0); return calendar; } 

Observe cómo una AlarmInstance almacena la hora exacta en que debe disparar, independientemente de la zona horaria. Esto asegura que cada vez que llame a getAlarmTime() obtenga la hora correcta para disparar en la zona horaria del usuario. El problema aquí es si la zona horaria no se actualiza, getAlarmTime() no puede obtener cambios de hora correctos, por ejemplo, cuando se inicia DST.

JodaTime es útil en este escenario porque se incluye con su propia base de datos de zona horaria. Puede considerar otras bibliotecas de fecha y hora tales como date4j para la conveniencia de mejores cálculos de fecha de manipulación, pero éstos típicamente no manejan sus propios datos de zona horaria.

Pero tener tus propios datos de zona horaria introduce una restricción a tu aplicación: no puedes confiar más en la zona horaria de Android. Esto significa que no puede utilizar su clase de Calendar o sus funciones de formato. JodaTime proporciona funciones de formato, así, utilizarlos. Si debe convertir a Calendar , en lugar de utilizar el método toCalendar() , cree uno similar al getAlarmTime() anterior en el que pasa el tiempo exacto que desea.

Alternativamente, podría comprobar si hay una diferencia de zona horaria y advierta al usuario como Matt Johnson sugirió en su comentario . Si decides seguir usando las funciones de Android y Joda, estoy de acuerdo con él:

Sí – con dos fuentes de verdad, si están fuera de sincronía, habrá desajustes. Compruebe las versiones, muestre una advertencia, pida ser puesto al día, etc. No hay probablemente mucho más que usted puede hacer que eso.

Excepto que hay una cosa más que puedes hacer: Puedes cambiar la zona horaria de Android tú mismo. Probablemente deberías avisar al usuario antes de hacerlo, pero entonces podrías obligar a Android a usar la misma zona horaria que Joda:

 public static boolean isSameOffset() { long now = System.currentTimeMillis(); return DateTimeZone.getDefault().getOffset(now) == TimeZone.getDefault().getOffset(now); } 

Después de comprobar, si no es lo mismo, puede cambiar la zona horaria de Android con una zona "falsa" que cree desde el desplazamiento de la información de zona horaria correcta de Joda:

 public static void updateTimeZone(Context c) { TimeZone tz = DateTimeZone.forOffsetMillis(DateTimeZone.getDefault().getOffset(System.currentTimeMillis())).toTimeZone(); AlarmManager mgr = (AlarmManager) c.getSystemService(Context.ALARM_SERVICE); mgr.setTimeZone(tz.getID()); } 

Recuerde que necesitará el <uses-permission android:name="android.permission.SET_TIME_ZONE"/> para eso.

Finalmente, cambiar la zona horaria cambiará la hora actual del sistema. Lamentablemente, sólo las aplicaciones del sistema pueden establecer el tiempo para que lo mejor que puede hacer es abrir la configuración de fecha y hora para el usuario y pedirle que lo cambie manualmente a la correcta:

 startActivity(new Intent(android.provider.Settings.ACTION_DATE_SETTINGS)); 

También tendrá que agregar más controles para asegurarse de que la zona horaria se actualiza cuando comienza y termina DST. Como has dicho, agregarás tu propia gestión de zona horaria, pero es la única manera de asegurar la coherencia entre las dos bases de datos de zona horaria.

Lo estás haciendo mal. Si el usuario agrega una entrada de calendario para las 9 am del próximo año, significa 9 am. No importa si la base de datos de zona horaria en el dispositivo del usuario cambia o el gobierno decide alterar el inicio o final del horario de verano. Lo que importa es lo que dicen los relojes en la pared. Debe almacenar "9 am" en su base de datos.

Esto es generalmente un problema imposible. Nunca puede almacenar el tiempo delta (por ejemplo, ms después de la época) para un evento futuro a una hora determinada del reloj de pared, y estar seguro de que permanecerá correcto. Considere que por cualquier tiempo arbitrario, una nación puede firmar una ley que el tiempo de ahorro de luz diurna entra en vigor 30 minutos antes de ese tiempo, y el tiempo se salta adelante por 1 hora. Una solución que puede mitigar este problema es, en lugar de pedirle al teléfono que se despierte a una hora específica, se despierta periódicamente, compruebe la hora actual y, a continuación, compruebe si se debe activar cualquier recordatorio. Esto se puede hacer de manera eficiente ajustando el tiempo de despertar para reflejar una idea aproximada de cuándo se establece el siguiente recordatorio. Por ejemplo, si el siguiente recordatorio no es para 1 año, despierte después de 360 ​​días y empiece a despertar con más frecuencia hasta que esté muy cerca de la hora del recordatorio.

Puesto que usted está usando AlarmManager , y parece que requiere que usted fije el tiempo en UTC, entonces usted es correcto en que usted necesitará proyectar su tiempo al UTC para programarlo.

Pero usted no tiene que persistir de esa manera. Por ejemplo, si tiene un evento diario que se repite, guarde la hora local del día en que debe desencadenarse el evento. Si el suceso debe producirse en una zona horaria específica (en lugar de la zona horaria actual del dispositivo), guarde esa ID de zona horaria también.

Proyecte la hora local a la hora UTC utilizando JodaTime – luego pase ese valor a AlarmManager .

Periódicamente (o al menos, cada vez que aplique una actualización a los datos de JodaTime), vuelva a evaluar las horas UTC planificadas. Cancelar y restablecer los eventos según sea necesario.

Tenga cuidado con los horarios programados durante una transición de horario de verano. Es posible que tenga un horario local que no sea válido en un día determinado (que probablemente debería ser avanzado), o puede tener una hora local que es ambigua en un día específico (que probablemente debería elegir la primera de las dos instancias).

En última instancia, creo que su preocupación es que sería posible que los datos de Joda Time sean más precisos que los datos del dispositivo. Por lo tanto, una alarma podría apagarse a la hora local correcta, pero podría no coincidir con la hora que se muestra en el dispositivo. Estoy de acuerdo en que podría ser desconcertante para el usuario final, pero probablemente estarán agradecidos de haber hecho lo correcto. No creo que haya mucho que puedas hacer al respecto de todos modos.

Una cosa que podría considerar es comprobar TimeUtils.getTimeZoneDatabaseVersion() y compararlo con el número de versión de los datos cargados en Joda Time. Si están fuera de sincronización, puede presentar un mensaje de advertencia a su usuario para actualizar su aplicación (cuando esté atrasado) o actualizar el tzdata de su dispositivo (cuando el dispositivo esté detrás).

Una búsqueda rápida encontró estas instrucciones y esta aplicación para actualizar el tzdata en Android. (No las he probado yo mismo.)