2009-01-26 17 views
7

Estoy desarrollando un software internacional que funciona como un software simple de administración de proyectos y estoy enfrentando un problema. Este problema es sobre la fecha/hora y la zona horaria.
Cuando se envía un mensaje de una zona horaria a otra zona horaria, puedo almacenar la hora UTC (GMT) en mi base de datos y luego hacer que se muestre de manera diferente según la zona horaria del usuario. Pero esto no se puede hacer cuando solo trabajo con la fecha.
Si digo que una tarea se debe realizar el 21 de marzo. ¿Debería considerar que esta fecha puede ser 20 o 22 en algunos otros países? ¿Cuáles son sus consejos sobre este problema?¿Cómo manejo la fecha y la hora en diferentes zonas horarias?

+0

¿Puedo colocar un enchufe desvergonzado para mi propia pregunta relacionada (pero diferente) sobre cómo probar el manejo correcto de zona horaria? http://stackoverflow.com/questions/477965/testing-correct-timezone-handling –

+1

Tienes que encontrar divertido que si buscas en las etiquetas "localización" o "internacionalización" solo recibas dos preguntas, pero si Si busca en "localización" o "internacionalización" obtendrá montones. – Evan

Respuesta

4

Digamos que un usuario en Nueva York establece una fecha de vencimiento para un proyecto como "en cualquier momento el lunes 26 de enero". Eso significa "en cualquier momento desde las 0600 del lunes 26 enero al 0600 martes 27 enero" en Bruselas y "desde el domingo 25 enero hasta el 2000 el lunes 26 enero" en LA

Completando la tarea a las 2100 el lunes 26 está bien en Bruselas y Nueva York, pero demasiado tarde en LA

Un posible problema no es solo trabajar con la fecha. Si no se especifica la hora, configúrela para 0000 horas o 2400 horas en la fecha especificada en la zona horaria del usuario.

Los usuarios pueden tener que lidiar con fechas/horas de vencimiento extrañas, pero hablar como alguien que solía trabajar internacionalmente, va un poco con el territorio.

2

No podrá lograr lo que está tratando de hacer sin almacenar la hora exacta. Simplemente no tienes suficiente información.

2

Cuando no disponga de tiempo, suponga que el tiempo es el final de la actividad en la configuración regional principal de la aplicación, luego traduzca ese tiempo como lo haría en cualquier otro momento. Una alternativa sería asumir el final del día hábil en hora local y ajustarlo a UTC. Todos los que usen la aplicación necesitarán entender cualquier hipótesis de tiempo predeterminada que hagas cuando no se especifique la hora. La coordinación con la oficina principal puede ser mejor en una gran empresa, mientras que la coordinación a la hora local puede ser mejor en entornos altamente descentralizados donde el contexto local es igualmente importante.

+0

El final del día en UTC sería contraintuitivo para la persona que establece la fecha de vencimiento (a menos que, por supuesto, ya estén viviendo en ZULU). – officemonkey

+0

@officemonkey - es por eso que no fue mi primera sugerencia. Supongo que puede ser mejor elegir el final del día hábil en horario local y ajustarlo para todos los demás. Eso probablemente tenga más sentido para la persona que ingresa a la tarea. Ajustaré la respuesta. – tvanfosson

+0

Fin del negocio es demasiado vago. –

1

La solución más fácil sería simplemente mostrarla en la misma fecha para todos. La fecha límite sería efectivamente la medianoche en la última zona horaria.

De lo contrario, decida cuál debe ser el tiempo predeterminado de la fecha límite en la zona horaria en la que se creó la tarea, p. 21 de marzo a las 17:00 EST o 22 de marzo a las 00:00 EST y mostrar eso en la zona horaria local. La diferencia de zona horaria luego lo empujará al día anterior o al día siguiente para el espectador.

0

Si tiene una única instancia de un DB, almacenaría todas las fechas en la marca de tiempo datetime de su servidor de bases de datos. Si está marcando fechas, considere GetDate() en T-SQL o como valor predeterminado de la columna de fecha y hora. Entonces tienes tu punto de referencia único para todos los tiempos. Considere el formato UTC allí.

Entonces, todos los clientes que acceden a la fecha hacen su propia conversión en "hora local", que puede ser interpretado por cosas como: las preferencias del usuario, fecha de sello de tiempo en el ordenador cliente, etc.

Sin saber más, Es difícil decir exactamente cuál es la resolución.

1

SQL 2008 permite un tipo de datos de fecha que no tiene ningún valor de tiempo asociado. Eso le permite a alguien decir que lo necesito para esta fecha, pero no me importa si es +/- varias horas. Si la fecha seleccionada es 1/1/2009 pero ocurre el 1/2/2009 a las 2AM hora local, es probable que no les importe.

Cuando el usuario necesita algo hecho en una fecha y hora específicas, como el cierre de operaciones el 1/1/2009, entonces debe almacenarlo en un DateTime como UTC y convertirlo a la hora local del lado del cliente.

Esto eliminará la complejidad de indicar cuándo se completa algo, o se completará cerca de un día específico o en un momento específico.

2

Si no está almacenando los minutos y segundos, debe suponer que la fecha introducida es la fecha deseada y no a los ajustes para GMT. Simplemente colóquelo en la base de datos tal como está. Las personas en la costa oeste tendrán que suponer que la fecha de vencimiento es la misma independientemente de dónde se encuentre en el mundo. Si desea ajustar las zonas horarias, tendrá que recopilar más información, como horas, minutos y segundos.

0

Su solución depende de su aplicación y requisitos.

Primero almacenaría UTC + offset en sus estructuras de datos, por lo que es fácil de visualizar para cualquier zona horaria.

Lo más probable es que si una tarea o reunión debe realizarse a las 12pm del 21/marzo en Londres, ocurrirá a las 2130 el 21 de marzo en Adelaide (+0930), pero ese es un requisito de la aplicación. .

Si desea lo último en flexibilidad, agregue una bandera que pueda igualar simultáneamente en cada zona horaria o al mismo tiempo, sin importar dónde se encuentre (escalonado) y muestre el evento en consecuencia.

0

Es posible que desee guardar la fecha en a from que tenga en cuenta la zona horaria. Esto te ayudará en tus cálculos. SQL Server 2008, por ejemplo, admite un datetimeoffset that does precisely this. Alternativamente, si está utilizando SQL 2005 con un poco de esfuerzo, puede escribir su propio tipo de datos SQL CLR para respaldar esto.

Cuestiones relacionadas