El problema de la hora de reunión, y cómo lo resuelve Overlap

Añade a una persona por ciudad, por zona horaria IANA o por un desfase directo como UTC+3. Cada una recibe su fila: una banda de 24 horas con su día local, en gris mientras duerme, en ámbar mientras está despierta pero fuera de horario, y en verde dentro de su horario laboral.

El horario laboral es de cada persona, no global. Por defecto son las 09:00–18:00 en hora local y se cambia en la propia fila. Un programador que empieza a las 11:00 y un cliente que termina a las 16:00 conservan su día real, y el tablero responde en consecuencia.

Debajo del tablero, Overlap ordena las franjas de una hora: cuántas personas están dentro de su horario laboral, cuántas solo están despiertas y —cuando a nadie le toca fácil— quién exactamente tiene que ceder. Recibes una frase en lenguaje claro, no un acertijo de colores que descifrar.

Cada tablero vive en su propio enlace. Cópialo y quien lo abra verá las mismas personas, los mismos nombres, los mismos horarios laborales, la misma fecha y la misma referencia, todo leído según su propio reloj.

El cálculo mental sirve para dos ciudades que conoces bien. Se cae con cuatro ciudades que no conoces, y se rompe del todo la semana en que un país ya ha cambiado la hora y el otro todavía no.

Un reloj mundial te dice qué hora es en un sitio. No te dice si esa persona está durmiendo, cenando o tres horas metida en su jornada, que era justo lo único que necesitabas saber.

Una encuesta de disponibilidad le pide a todo el mundo que haga la conversión por ti. Es exactamente el trabajo que querías evitar, y ahora no se puede cerrar nada hasta que conteste el más lento.

La función de “buscar un hueco” del calendario funciona de maravilla dentro de una misma empresa con un mismo sistema de calendarios. No sabe nada del proveedor, del cliente ni del candidato con quien intentas reunirte.

Los desfases y las reglas del horario de verano salen de la propia base de datos de zonas horarias IANA del navegador, a través de la API estándar Intl. No hay ninguna tabla de desfases que se quede obsoleta: si el navegador conoce un cambio de norma, el tablero también.

El horario de verano se resuelve por persona y por fecha, no una sola vez para todo el tablero. Elige una fecha de finales de marzo o de finales de octubre y mira cómo se deslizan las bandas: el día en que el reloj se adelanta se dibuja con 46 columnas de media hora y el día en que se atrasa con 50, porque esa es la duración real de esos días.

Las columnas son de media hora, así que las zonas a :30 y a :45 —India, Nepal, las islas Chatham— encajan con honestidad en lugar de redondearse a la hora más cercana.

El tablero se dibuja sobre el día de calendario de una sola persona —la referencia—, y tú eliges de quién. Eso importa cuando una franja cae después de medianoche para alguien: la fila muestra “día sig.” en vez de dar la vuelta sin avisar.

Las franjas se puntúan, no se adivinan. Estar trabajando puntúa al máximo, estar despierto cerca del horario laboral puntúa a medias, y estar durmiendo descarta la franja por completo. Las candidatas se mantienen separadas al menos dos horas para que las tres sugerencias sean opciones realmente distintas, y cada persona recibe una etiqueta de temprano, tarde o fuera de horario.

Cualquier franja se exporta a un archivo de calendario. La descripción del evento lleva la hora de inicio local de cada persona y un enlace de vuelta al tablero, así que los invitados pueden comprobar el razonamiento por su cuenta.

Para una llamada periódica sin ninguna hora cómoda existe la rotación justa: desplaza la franja incómoda semana a semana para que no sea siempre la misma persona la que atiende la llamada a las 22:00.

No se guarda nada en ningún servidor. No hay cuenta, ni cookie de seguimiento, ni registro de con quién te reúnes: el tablero está codificado en la URL y el índice de ciudades es un archivo estático que tu navegador descarga una vez. Los equipos guardados viven en el almacenamiento de tu propio navegador y nunca salen del dispositivo.