> Как решать проблему работы с разными часовыми поясами в распределенной команде (Go)

Короткий ответ

Проблема часовых поясов в распределённой команде решается единым стандартом хранения времени - UTC, с конвертацией в локальный пояс только на уровне представления. На практике это означает: все timestamps в БД и API хранятся в UTC, все сервисы работают с UTC, а клиент сам преобразует время для пользователя. Для планирования событий в будущем (встречи, дедлайны) храним instant + IANA timezone, а не локальное время. В Go используем time.Time с явным location и time.LoadLocation.

Подробное объяснение

Основная сложность - не в хранении, а в интерпретации. Если хранить локальное время, то одно и то же значение может означать разный момент в разных поясах, плюс DST (переход на летнее время) ломает арифметику. Поэтому:

1. Хранение: всегда UTC. Для Go это time.Time с UTC() при сериализации. В PostgreSQL - timestamptz, который хранит instant и нормализует при чтении.

2. Передача: API отдаёт RFC3339 с offset или Z. Клиент (браузер, мобильное приложение) конвертирует в локальный пояс через Intl.DateTimeFormat или аналоги.

3. Будущие события: для встреч и дедлайнов храним пару (instant, timezone). Например, встреча в 10:00 в Нью-Йорке - это 2025-06-01T14:00:00Z + America/New_York. Если DST изменится, мы пересчитаем instant, но сохраним локальное намерение.

4. Агрегации и отчёты: всегда в UTC. Если нужен локальный день (например, "отчёты за день по Москве"), определяем границы дня через time.LoadLocation("Europe/Moscow") и конвертируем.

5. Коммуникация в команде: все обсуждения и статусы - в UTC, с явным указанием пояса, если это важно. Никаких "10:00" без уточнения.

На практике

• В Go используем time.Now().UTC() для текущего времени, никогда time.Now() без location.
• Для парсинга входящих данных - time.Parse(time.RFC3339, s), затем .UTC().
• Для вывода в API - t.Format(time.RFC3339) (уже с Z, если UTC).
• Для работы с поясами - time.LoadLocation("Europe/Berlin"), кэшируем результат (это дорогая операция).
• В БД - колонки timestamptz, не timestamp without time zone.
• Для cron-задач, если они привязаны к локальному времени (например, "в 9 утра по Токио"), вычисляем следующий запуск через location, а не храним фиксированный UTC-крон.

Пример кода

GO
package main

import (
    "fmt"
    "time"
)

func main() {
    // Текущее время в UTC
    now := time.Now().UTC()
    fmt.Println("now UTC:", now.Format(time.RFC3339))

    // Парсинг входящего времени
    input := "2025-06-01T14:00:00Z"
    t, err := time.Parse(time.RFC3339, input)
    if err != nil {
        panic(err)
    }
    fmt.Println("parsed:", t.UTC().Format(time.RFC3339))

    // Конвертация в локальный пояс для пользователя
    loc, err := time.LoadLocation("America/New_York")
    if err != nil {
        panic(err)
    }
    local := t.In(loc)
    fmt.Println("NY time:", local.Format("2006-01-02 15:04 MST"))

    // Будущее событие: instant + timezone
    meeting := time.Date(2025, 6, 1, 10, 0, 0, 0, loc)
    fmt.Println("meeting instant:", meeting.UTC().Format(time.RFC3339))
    fmt.Println("meeting local:", meeting.Format("2006-01-02 15:04 MST"))

    // Границы дня в конкретном поясе
    dayStart := time.Date(2025, 6, 1, 0, 0, 0, 0, loc)
    dayEnd := dayStart.Add(24 * time.Hour)
    fmt.Printf("day range: %s - %s\n", dayStart.UTC(), dayEnd.UTC())
}

Как отвечать на собеседовании

Начни с главного принципа: UTC как единственный формат хранения. Затем добавь нюанс с будущими событиями и DST - это показывает глубину. Упомяни, что в Go time.Time хранит instant, а location - это только представление, и что LoadLocation нужно кэшировать. Если спросят про БД - скажи про timestamptz. Приведи пример из практики: баг с DST, когда встреча сдвинулась на час, и как это решили парой (instant, timezone).

Что проверяет интервьюер

• Понимание разницы между instant и локальным временем.
• Знание проблем DST и арифметики с time.Time.
• Умение проектировать API и хранение с учётом поясов.
• Практический опыт с Go: time.LoadLocation, time.RFC3339, работа с location.
• Способность объяснить trade-off между простотой (всё в UTC) и корректностью для будущих событий.

Типичные ошибки

• Хранение локального времени в БД без пояса.
• Использование time.Now() без .UTC() в бизнес-логике.
• Игнорирование DST при планировании будущих событий (фиксированный UTC-offset ломается).
• Смешивание time.Time с разными location в сравнениях (Go сравнивает по instant, но путаница в коде).
• Неправильный парсинг: time.Parse("2006-01-02 15:04:05", s) без пояса - получите UTC, а не локальное.
• Кэширование time.LoadLocation в каждом вызове - это syscall, лучше один раз в init или sync.Once.