Introducción
Fechas y marcas horarias están presentes en casi todos los procesos empresariales: cuándo se hizo un pedido, cuándo debe salir una entrega o a qué hora fichó un empleado. En Odoo, el campo Datetime es la forma estándar de capturar ese tipo de información con fecha y hora exactas.
A diferencia de un campo Date que sólo guarda un día del calendario, el Datetime registra la fecha y la hora precisa (horas, minutos y segundos). Esa precisión importa, sobre todo en entornos con usuarios en distintas zonas horarias o cuando las operaciones se miden por horas o minutos.
Esta guía reúne lo esencial sobre el campo Datetime en Odoo: qué datos guarda, cómo actúa en el modelo de datos, cómo crear y configurar uno desde Studio o código Python, y ejemplos prácticos extraídos de flujos reales de trabajo.
¿Qué es el campo Datetime en Odoo?
En el ORM de Odoo, fields.Datetime almacena un valor combinado de fecha y hora con precisión de segundos. En la base de datos corresponde a una columna TIMESTAMP en PostgreSQL. Internamente Odoo guarda estos valores en UTC y se encarga de convertirlos a la zona horaria del usuario activo cuando los muestra en pantalla.
Para el usuario, un Datetime se presenta como un selector que combina calendario y hora dentro de un mismo campo. En listas e informes, ese valor se formatea según el idioma y la configuración horaria del usuario activo, mostrando la hora local en lugar del UTC almacenado.
Así se define un campo Datetime en un modelo Python:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_confirmed_on = fields.Datetime(
string='Confirmed On',
default=fields.Datetime.now,
readonly=True,
copy=False,
)El parámetro string establece la etiqueta visible en la interfaz. default permite rellenar el campo automáticamente con la marca temporal actual al crear un registro. readonly evita modificaciones manuales, práctica habitual para marcas de auditoría.
En Odoo Studio este tipo aparece como Date & Time. Los campos creados desde Studio reciben automáticamente el prefijo x_studio_. Si lo creas vía código o mediante la API XML-RPC, tú defines el nombre técnico del campo.
Cómo funciona el campo
Cuando defines un Datetime en un módulo, Odoo crea la columna correspondiente en la base de datos durante la instalación o actualización del módulo; no es necesario escribir migraciones SQL manuales.
Un aspecto que suele generar dudas es el manejo de zonas horarias. La base de datos guarda siempre UTC: si un usuario en París fija una reunión a las 15:00, Odoo almacena 13:00 UTC. Otro usuario en Nueva York verá la hora convertida a su horario local. El ORM realiza esa conversión automáticamente según la zona horaria configurada en cada perfil de usuario.
Atributos clave del campo
Estas son las propiedades más importantes del campo Datetime en Odoo:
- default: Su valor suele fijarse a
fields.Datetime.nowpara rellenar automáticamente con la hora actual en UTC al crear un registro. - required: Obliga a completar el campo en formularios y a nivel de modelo.
- readonly: Impide la edición manual desde la interfaz; útil para marcas generadas por el sistema.
- compute: Permite calcular el valor mediante un método Python en función de otros campos o reglas de negocio.
- store: Si se usa junto a
compute, persiste el valor calculado en la base de datos para búsquedas y reportes. - copy: Controla si el valor se duplica al copiar un registro. Por defecto es
True; para marcas temporales que no deben heredarse, ponFalse. - index: Crea un índice en la base de datos, recomendable en campos que se usan mucho en filtros, como fechas programadas en tablas grandes.
Cómo aparece en las vistas
En vistas de formulario, un Datetime ofrece un selector combinado de fecha y hora: calendario y entrada de hora en un mismo control. En vistas de lista se muestra como cadena formateada según el idioma del usuario. En las vistas de búsqueda admite filtros por rangos: antes, después o entre periodos concretos.
También puedes usar el widget date_range para mostrar una selección de rango directamente en el formulario, útil en ventanas de programación o tareas con límites temporales.
Datetime vs Date: elegir el campo adecuado
La regla práctica es simple: usa fields.Date cuando la hora no importa; usa fields.Datetime cuando necesites precisión a nivel de hora o minuto.
Usa Date para fechas que solo precisan día: vencimientos de factura, cumpleaños, caducidad de producto o renovaciones contractuales.
Usa Datetime para marcas que requieren hora: confirmaciones de pedidos, comienzo de reuniones, registros de presencia o operaciones logísticas programadas.
Emplear Datetime cuando no hace falta añade complejidad por las zonas horarias sin aportar valor. Si dudas, pregunta si la hora del día afecta al proceso que modelas.
Casos de uso en la empresa
El campo Datetime está presente en casi todos los módulos de Odoo. A continuación, cinco ejemplos prácticos de uso en procesos reales.
CRM: seguimiento de actividades del lead
En CRM varios Datetime nativos registran eventos clave: date_open marca cuándo un lead pasa a En Progreso y date_deadline programa seguimientos. Los responsables comerciales usan estos datos para medir tiempos de respuesta, detectar oportunidades estancadas y generar informes. Campos personalizados permiten, por ejemplo, anotar cuándo se envió una propuesta o la hora exacta de una llamada importante.
Ventas: marcas de confirmación de pedido
El campo date_order en sale.order es un Datetime que registra el instante exacto de la confirmación de una venta. Sirve para informes por hora o día, calcular tiempos de procesamiento y auditar cambios posteriores. Filtrar pedidos por esta fecha es una operación de reporting muy habitual en equipos comerciales.
Inventario: fechas de traslado programadas
En stock.picking, scheduled_date es un Datetime que planifica recepción o envío. Las acciones automatizadas pueden dispararse según la diferencia entre esta fecha y el tiempo actual; por ejemplo, avisos automáticos cuando una entrega lleva horas de retraso para informar proactivamente al cliente.
Fabricación: horas de inicio y fin de producción
Las órdenes de fabricación usan Datetime para marcar inicio y fin de producción. Estos datos alimentan planificación de capacidad, análisis de eficiencia y rendimiento. En plantas con varios turnos, la precisión horaria es esencial para comparar lo planificado frente a lo real y localizar cuellos de botella según la franja horaria o el operario.
RRHH: control de asistencia y ausencias
En RRHH, la asistencia registra fichajes de entrada y salida con Datetime. Las solicitudes de permiso pueden definir inicio y fin exacto mediante Datetime. Nóminas y reglas de horas extra dependen de estos registros minuto a minuto; cualquier error o ausencia en las marcas puede alterar el cálculo salarial, por ello la precisión no es opcional sino un requisito de negocio.
Crear o personalizar un campo Datetime
Tres formas de añadir un campo Datetime a un modelo Odoo según tu entorno y nivel técnico.
Con Odoo Studio (sin código)
Odoo Studio permite añadir campos sin escribir código. Pasos para añadir un Datetime con Studio:
- Abre Odoo Studio desde el menú principal.
- Navega al formulario donde quieres añadir el campo.
- Arrastra un campo Date & Time desde la barra lateral al formulario.
- Configura etiqueta, obligatoriedad y, si procede, un valor por defecto en las propiedades del campo.
- Guarda y cierra Studio.
Studio crea el campo con prefijo x_studio_ y lo incorpora a la vista. No necesitas migraciones SQL; Odoo lo gestiona al guardar. Es la vía recomendada para usuarios de negocio que quieren añadir un timestamp sin depender de desarrolladores.
Con Python en un módulo personalizado
Los desarrolladores definen Datetime en archivos Python de modelos. Es la opción recomendable cuando la personalización debe controlarse con versiones y desplegarse entre entornos:
from odoo import fields, models
class ResPartner(models.Model):
_inherit = 'res.partner'
x_last_contact_date = fields.Datetime(
string='Last Contact Date',
default=fields.Datetime.now,
copy=False,
)Tras definir el campo, añádelo al XML de la vista relevante para que aparezca en la interfaz. Al instalar o actualizar el módulo, Odoo crea la columna TIMESTAMP automáticamente; no se requiere SQL manual.
A través de la API XML-RPC
Si gestionas personalizaciones de forma programada (por ejemplo en despliegues automatizados), puedes crear campos Datetime mediante la API XML-RPC:
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_last_contact_date',
'field_description': 'Last Contact Date',
'model_id': model_id,
'ttype': 'datetime',
'state': 'manual',
}]
)El ttype: datetime indica a Odoo que cree un campo Datetime. state: manual marca que el campo se creó fuera de la instalación de un módulo, la configuración adecuada para campos generados por Studio o por la API en scripts de configuración remota.
Buenas prácticas
1. Usa fields.Datetime.now como referencia de función, no la llames
Al fijar un default escribe default=fields.Datetime.now sin paréntesis. Si pones paréntesis, Python evalúa la función al cargar la clase y todas las fichas creadas después compartirán esa misma marca temporal congelada. Sin paréntesis, Odoo invoca la función al crear cada registro, obteniendo un timestamp correcto por registro.
2. Pon copy=False en marcas de evento
Si el campo registra cuándo ocurrió algo (confirmación, finalización), usa copy=False. Al duplicar un registro no debe heredarse la marca temporal original. Sin esto, los registros duplicados contienen datos históricos que falsean análisis y auditorías.
3. Escribe siempre en UTC cuando uses la API
Al crear o actualizar registros vía XML-RPC, pasa valores Datetime en UTC con formato YYYY-MM-DD HH:MM:SS. La API no convierte zonas horarias al escribir; lo que le envías se guarda como UTC, así que pasar una hora local introduce un desfase difícil de depurar después.
4. Usa readonly para timestamps auto-generados
Las marcas que reflejan eventos del sistema deben ir generalmente en modo readonly en la interfaz. Evita que los usuarios editen manualmente esas marcas; si hay una excepción legítima, controla el acceso mediante los permisos a nivel de campo en lugar de dejar el campo editable para todos.
5. Elige Date cuando la hora no sea necesaria
Si solo hace falta un día del calendario (plazos de entrega, vencimientos, fechas de renovación), usa fields.Date. Datetime añade gestión de zonas horarias sin aportar valor si la componente horaria es irrelevante; mantener el tipo más simple facilita el mantenimiento del modelo de datos.
Errores frecuentes
Confusión por zonas horarias al leer valores crudos
La mayor fuente de problemas son las lecturas directas de la base de datos o la API: muestran UTC, no la hora local del usuario. Muchos integradores generan informes con esos valores sin convertir la zona horaria y obtienen marcas adelantadas o retrasadas. Convierte siempre a la zona horaria del usuario en el cliente y documenta ese paso en cualquier integración.
Escribir horas localizadas vía API
Si envías a la API una hora ya localizada, la base de datos la tratará como UTC. Por ejemplo, escribir 2026-01-01 15:00:00 suponiendo hora de París puede acabar mostrando 16:00 o 17:00 según si es horario de verano, creando un fallo que normalmente solo se detecta en producción cuando usuarios reales interactúan con el sistema.
Usar default=fields.Datetime.now() con paréntesis
Poner paréntesis en el default es un error sutil pero grave: fields.Datetime.now() se evalúa al cargar la clase y todas las entradas creadas después tendrán la misma marca congelada. Los datos parecerán correctos al principio, pero cualquier análisis temporal quedará dañado por registros idénticos en la fecha de creación.
Olvidar copy=False en marcas de evento
Sin copy=False, al duplicar un registro se arrastran las marcas temporales originales. Una fecha de confirmación o el inicio de producción del registro fuente aparecerán en el duplicado, contaminando informes históricos y rompiendo trazabilidad. Un ajuste pequeño con un impacto grande en la calidad de datos.
Usar Datetime cuando Date basta
Elegir Datetime para un vencimiento de factura o la caducidad de un producto añade fricción: los usuarios ven una hora innecesaria, el sistema calcula zonas horarias sin motivo y la interfaz gana complejidad sin beneficio. Opta por el tipo más simple que cumpla la necesidad de negocio.
Conclusión
El campo Datetime es de los más versátiles de Odoo cuando hace falta precisión. Desde marcar la apertura de un lead hasta registrar inicio de producción o fichajes, aparece en casi todos los módulos y aporta información crítica para operaciones y análisis.
Lo fundamental que hay que recordar es el modelo de almacenamiento en UTC. Todo se guarda en UTC en la base de datos; la interfaz convierte para mostrar la hora local del usuario. La mayoría de errores relacionados con zonas horarias en integraciones vienen de no tener esto presente.
Además, usar la sintaxis correcta para defaults, aplicar copy=False cuando corresponda y preferir Date sobre Datetime si la hora no importa mantendrá tu modelo de datos limpio y tus informes fiables.
En Dasolo ayudamos a empresas a implementar, personalizar y optimizar Odoo en todas las áreas. Si necesitas apoyo para diseñar un modelo de datos robusto, añadir campos personalizados a tus flujos o desarrollar un módulo completo, nuestro equipo puede acompañarte. Ponte en contacto con nosotros y hablemos de tu proyecto Odoo.