¿Debe el encabezado "Fecha" del correo electrónico ser la hora local del remitente o UTC?

Escribo un cliente de correo electrónico basado en la web en Python y ha surgido una pregunta acerca de qué zona horaria debe representarse el encabezado "Fecha" de un correo electrónico como cuando se envía.¿Debe el encabezado "Fecha" del correo electrónico ser la hora local del remitente o UTC?

RFC 2822 estados en la sección 3.3 que:

La fecha y la hora del día debe expresar hora local.

Esto me parece ambiguo; la pregunta es la hora local de quién? El servidor de correo electrónico, o el remitente? Naturalmente, supongo que el remitente (que podría estar en cualquier zona horaria, y se puede cambiar en las preferencias de su cuenta). Se produjo una mayor confusión cuando miré la función email.utils.formatdate de Python que parece ofrecer solo dos alternativas: UTC o hora local (del servidor). Para mí no parece haber ninguna opción de especificar una zona horaria alternativa, ¿o me falta algo?

Pasar un timeval para formatear la fecha usando time.mktime(senders_tz_aware_now_datetime.timetuple()) da como resultado una cadena de fecha UTC, que se siente mal dado lo que dice el RFC arriba.

Entonces, ¿qué zona horaria debe tener "Fecha" y existe alguna función estándar para crear la cadena de fecha adecuada?

Fuente

2012-05-07 kuhnza

Simplemente usa UTC y estarás más feliz.

Eso es lo que sucede cuando las especificaciones usan términos como DEBERÍA. Creo que ambos DEBERÍAN estar prohibidos en las especificaciones porque siempre crean complejidad innecesaria.

El uso de UTC es perfectamente válido.

Fuente

2012-05-07 18:46:35 sorin

Eso no va a funcionar, estoy convirtiendo un objeto datetime con zona horaria utilizando el método timupuple, lo que significa que is_dst ya está configurado. Tampoco responde mi pregunta sobre cuál es la representación correcta de la fecha y hora. – kuhnza

Cambié de opinión, vaya de la manera más fácil y tendrá tiempo para tomar una cerveza por la noche. – sorin

Haha Me gusta tu estilo. Aún así, me gustaría tener una idea de cómo se maneja comúnmente porque me imagino que tiene implicaciones en una gama de clientes de correo electrónico de la que nunca he oído hablar, y mucho menos con el tiempo o los recursos para probar. – kuhnza

Si desea adherirse a la RFC, pase localtime=True que devuelve una cadena de fecha con la hora local y la zona horaria correcta (suponiendo que la tiene configurada correctamente).

>>> email.utils.formatdate(localtime=True) 
'Mon, 07 May 2012 12:09:16 -0700'

Sin localtime=True se obtiene una cadena de fecha que representa la hora UTC:

>>> email.utils.formatdate() 
'Mon, 07 May 2012 19:08:55 -0000'

-0000 aparentemente indica GMT, aunque el RFC recomienda específicamente el uso de +0000. No estoy seguro si esto es un error en email.utils.

Aquí está la documentación de Python relevante:

hora local opcional es una bandera que cuando cierto que interpreta timeval, y devuelve una fecha relativa a la zona horaria local en lugar de UTC, teniendo debidamente horario de verano en cuenta. El valor predeterminado es False, lo que significa que se usa UTC.

Fuente

2012-05-07 19:11:26 spinlok

Gracias, por supuesto, esto es lo que inicialmente pensamos que haría el truco. Lamentablemente, su respuesta plantea la misma pregunta que me ha dejado perplejo: ¿cuál es "la zona horaria correcta"? El ajuste 'localtime = True' devuelve el huso horario del servidor, no el del remitente. De ahí mi pregunta, ¿debería ser la zona horaria local del servidor o el remitente? Uno supondría que la zona horaria del remitente es lo correcto. Sin embargo, en este caso, no puedo ver que la fecha de formateo proporcione la funcionalidad necesaria para hacerlo. – kuhnza

No importa en qué zona horaria esté el remitente siempre que genere una marca de tiempo constante que represente la hora a la que se envió el correo electrónico. Depende del cliente del receptor interpretarlo correctamente. Es por eso que @Sorin sugirió ir con UTC, que es la manera más simple. – spinlok

Estoy de acuerdo en que no debería importar pero me molesta que el RFC diga que DEBE aparecer como hora local. – kuhnza

Esto aparece como un resultado superior al buscar en Google "hora local del cliente de correo electrónico"; Desafortunadamente, las dos respuestas y los comentarios que la acompañan apenas abordan la implementación de Python, y no logran hablar por completo a la línea de asunto (que es lo que está alimentando la respuesta de Google).

El RFC no es ambiguo porque es obvio: el encabezado "^ Date:" es local en el momento en que está escrito. El cliente de correo generalmente escribe el encabezado "^ Date:" (en cualquiera de las muchas implementaciones con las que he tratado). Para la mayoría de los clientes (configurados correctamente), esta será la hora local según lo informado por el sistema operativo del cliente.

En el caso de webmail, la hora local podría ser suministrada por el agente de usuario (que normalmente obtiene su hora local del SO a su vez). Más típicamente lo establecería el usuario dentro de la aplicación web (a la gmail).

Es importante saber que si "sigue el RFC" (probablemente una buena idea para un protocolo de red), el comportamiento resultante en los clientes RECEPTORES generalmente será mostrar la fecha en que se envió el correo tal como lo vio el remitente. Este es el punto de "DEBERÍA" en el RFC. No quiero ver UTC cuando trato de averiguar a qué hora un colega envió un correo electrónico; Quiero su hora local. De esta forma, puedo deducir la diferencia de tiempo en un paso (su hora local en la mía), no dos (su hora local para UTC a mi hora local). También recibo pistas inmediatas sobre el contexto de sus comunicaciones (¿era de noche? ¿Horas de trabajo ?, etc.).

Fuente

2016-01-20 22:22:16 ccy

¿Debe el encabezado "Fecha" del correo electrónico ser la hora local del remitente o UTC?

Respuesta

Cuestiones relacionadas