Когда ваше приложение запускается в больших масштабах, количество пользователей увеличится. Очень вероятно, что местоположение пользователя будет не только в той же области, но и в другой области с другим часовым поясом. Поэтому бэкенд-разработчику очень важно подумать о вещах, связанных с обработкой разницы в часовых поясах.

Недавно я столкнулся с проблемой, связанной с часовыми поясами. Давайте будем честными: работа с датами и временем — одна из самых сложных областей, с которыми приходится сталкиваться человеку. И для меня это была возможность научиться правильно обрабатывать дату и время на стороне сервера.

В этой статье я поделюсь своим опытом обработки разницы часовых поясов на стороне сервера в качестве бэкенд-разработчика. Возможно, если кто-то захочет исправить и предоставить дополнительную информацию, это будет для меня ценно.

О часовом поясе

Часовые пояса — это стандартная система разделения времени, используемая во всем мире для организации и стандартизации измерения времени. Эта концепция возникла как ответ на необходимость глобальной координации времени, особенно наряду с развитием технологий связи и транспорта.

Основным принципом часовых поясов является деление Земли на 24 пояса. Каждый часовой пояс обычно на один час отличается от соседнего с ним часового пояса. Основным ориентиром для часовых поясов является среднее время по Гринвичу (GMT) или всемирное координированное время (UTC), которое находится на линии нулевого градуса долготы, проходящей через Гринвич, Англия.

Иллюстрация Хеллерика из Wikimedia Commons

Небольшой пример: когда в Джакарте часы показывают 12:00, в Нью-Йорке время показывает 00:00 или полночь. Это означает, что пока жители Джакарты наслаждаются обедом, жители Нью-Йорка только начинают свой новый день. Отсюда вы, безусловно, можете себе представить, насколько важно правильно обрабатывать часовые пояса при создании приложения.

Обработка часового пояса на стороне сервера

После того, как мы ознакомились с приведенным выше объяснением, теперь мы перейдем к пунктам, которые можно сделать, когда наше серверное приложение получает запрос от клиента, который обращается к нашему API для обработки своего часового пояса.

В этой статье я расскажу о нескольких подходах к работе с часовыми поясами на стороне сервера. Здесь я буду использовать примеры кода на языке Golang (Go). В Golang имеется пакет времени для работы с данными, привязанными ко времени, который считается вполне полным. Вот некоторые моменты, которые мы обсудим:

• Как сохранить дату в БД
• Преобразование местного времени пользователя
• Тестирование и проверка

Как сохранить дату в БД

Первое, что мы обсудим, это то, какое время мы будем сохранять в базе данных, например, у нас есть приложение для электронной коммерции, которое осуществляет флэш-продажи, и наше приложение уже находится в международном масштабе.

Когда пользователь обрабатывает транзакцию покупки в Америке или если пользователь находится в Индонезии, он отправит на сервер другое местное время. Вопрос в том, будет ли наша база данных хранить данные о времени в соответствии с местным временем пользователя? Если ответ «да», то, скорее всего, это сложная проблема, когда мы хотим получить данные или, например, администратор хочет выполнить обработку данных, и какой пользователь совершает самую раннюю транзакцию.

Чтобы преодолеть эту проблему, рекомендуется хранить время транзакций в часовом поясе UTC (Всемирное координированное время), который является основным стандартом времени для часов и настроек времени. Вот применение времени к UTC.

package main

import (
    "fmt"
    "time"
)

func main() {

    now := time.Now()
    fmt.Printf("Local time: %s\n", now)

    nowInUTC := now.UTC()
    fmt.Printf("UTC time: %s\n", nowInUTC)

}

Давайте посмотрим, что означает приведенный выше код.

Во-первых, в строке кода now := time.Now() эта строка использует функцию Now() из пакета time для получения текущего времени на основе местного часового пояса системы. Результат сохраняется в текущей переменной.

Затем в строке nowInUTC := now.UTC() мы конвертируем местное время (сейчас) во время UTC с помощью метода UTC(). Результаты сохраняются в новой переменной nowInUTC и на этот раз могут храниться на сервере, где разработчики надеются избежать двусмысленности и ошибок, которые могут возникнуть из-за разницы часовых поясов между серверами и пользователями в различных регионах с разными часовыми поясами.

Вот результаты, если мы запустим приведенный выше код:

Но это не всегда лучшее решение, которое вам следует использовать. Возможно, в определенных случаях использования следует учитывать некоторые моменты, один из которых: правда ли, что наши пользователи происходят из разных часовых поясов? Если это невозможно, возможно, сохранение времени в формате UTC усложнит ваш код.

Изменить время на локаль пользователя

Выше мы договорились хранить данные о времени пользователя в одном месте, а именно в формате UTC. Теперь пользователи могут видеть точное время в зависимости от своего местоположения. Примером приведенного выше обсуждения является мгновенная распродажа в нашем приложении электронной коммерции, где пользователи также хотят знать информацию о том, какой пользователь совершил первую транзакцию. Итак, на данный момент преобразование времени, которое мы храним в базе данных, в местное время пользователя — это еще одна важная вещь, которую мы не должны игнорировать.

Я придерживаюсь подхода, заключающегося в том, что серверная сторона всегда просит клиента отправить часовой пояс на стороне пользователя. Это можно сделать на стороне запроса, когда клиент отправляет заголовок с ключевым часовым поясом и значением часового пояса пользователя. Например, в Индонезии есть 3 часовых пояса, а именно WIT(9), WITA(8), WIB(7). Где каждая зона имеет разницу в 1 час. Если раньше на нашем сервере мы хранили время UTC в 00.00, то на стороне WIT оно было 09.00, затем на стороне WITA оно было 08.00 и WIB 07.00.

Вот пример кода для обработки описанного выше случая:

package main

import (
    "fmt"
    "time"
)

func ParseTimezoneFromString(tz string) *time.Location {

    if len(tz) > 0 {

        t, err := time.Parse("2006 -07:00", fmt.Sprintf("2007 %s", tz))

        if err != nil {

            panic(err)

        } else {

            return t.Location()
        }
    }

    return time.Now().Location()
}

func main() {

    timeServerInUTC := "2024-08-04 00:00:00"
    nowInUTC, err := time.Parse("2006-01-02 15:04:05", timeServerInUTC)
    if err != nil {
        panic(err)
    }

    fmt.Printf("UTC time: %s\n", nowInUTC)

    witLocation := ParseTimezoneFromString(" 09:00")

    nowInWIT := nowInUTC.In(witLocation)
    fmt.Printf("WIT time: %s\n", nowInWIT)

    witaLocation := ParseTimezoneFromString(" 08:00")

    nowInWITA := nowInUTC.In(witaLocation)
    fmt.Printf("WITA time: %s\n", nowInWITA)

    wibLocation := ParseTimezoneFromString(" 07:00")

    nowInWIB := nowInUTC.In(wibLocation)
    fmt.Printf("WIB time: %s\n", nowInWIB)

}

благодарность dikac за создание этой функции ParseTimezoneFromString

Давайте разберемся в значении приведенного выше кода:

Сначала мы создаем функцию ParseTimezoneFromString, где эта функция используется для поиска местоположения времени на основе аргумента tz или часового пояса данного местоположения пользователя. Если строковое значение tz допустимо, мы преобразуем часовой пояс строки с помощью функции time.Parse для преобразования строки в объект времени, а затем извлекаем местоположение (часовой пояс) из этого объекта. И мы также обрабатываем, если строка пуста или синтаксический анализ не удался, функция возвращает местный часовой пояс системы.

func ParseTimezoneFromString(tz string) *time.Location {

    if len(tz) > 0 {

        t, err := time.Parse("2006 -07:00", fmt.Sprintf("2007 %s", tz))

        if err != nil {

            panic(err)

        } else {

            return t.Location()
        }
    }

    return time.Now().Location()
}

Далее мы также определяем данные времени в следующем строковом формате:

timeServerInUTC := "2024-08-04 00:00:00"

nowInUTC, err := time.Parse("2006-01-02 15:04:05", timeServerInUTC)
if err != nil {
    panic(err)
}

Вы можете думать об этом как о данных о времени, которые мы получаем с сервера. И проанализировать его в объект времени.

Далее мы пытаемся найти точное местоположение пользователя на основе функции ParseTimezoneFromString, которую мы ранее создали на основе определенного нами строкового аргумента. На что следует обратить внимание, так это на то, что под этим строковым аргументом понимается значение заголовка часового пояса, отправленное клиентом через входящий запрос.

Мы можем использовать местоположение, полученное из функции ParseTimezoneFromString, для преобразования или смещения времени, получаемого с сервера, в местное время пользователя. Мы можем сделать это с помощью функции In, которая также включена в пакет времени, который мы можем увидеть в следующем фрагменте кода:

nowInWIT := nowInUTC.In(witLocation)
nowInWITA := nowInUTC.In(witaLocation)
nowInWIB := nowInUTC.In(wibLocation)

Если мы запустим его, мы получим время, соответствующее определенному нами часовому поясу.

Тестирование и проверка

Последний пункт не менее важен, а именно тестирование и валидация. Когда процесс разработки часто приводит к неожиданным ошибкам, тестирование и проверка всегда важны.

При обсуждении пункта 2 выше функция ParseTimezoneFromString сыграла важную роль в обработке наших часовых поясов. Повторное тестирование и проверка важны для того, чтобы наши приложения получали результаты, соответствующие нашим ожиданиям.

Для тестирования рекомендуется использовать модульные тесты, где тестирование будет проводиться на самом маленьком модуле с возможностью добавления нескольких сценариев. Чем больше сценариев, тем меньше вероятность справиться с этой разницей во времени.

Заключение

Обработка часовых поясов действительно может быть сложной задачей для разработчиков серверной части. Однако важно помнить, что каждая сложная задача, которую мы решаем, способствует нашему росту и совершенствованию навыков. Правильное управление часовыми поясами — это не просто техническая необходимость, оно обеспечивает точность планирования и удобство работы для пользователей нашего приложения в разных регионах.

Рассмотренные в этой статье моменты, касающиеся хранения времени в формате UTC, преобразования в местное время пользователя и реализации надежных функций преобразования, являются отправной точкой в ​​решении этой сложной проблемы. Однако я признаю, что в обсуждаемых подходах могут быть недостатки или области для улучшения. Вот почему дополнительный вклад и предложения сообщества разработчиков неоценимы.

Я искренне надеюсь, что идеи и примеры кода, представленные в этой статье, пригодятся вам в будущем, когда вы столкнетесь с проблемами, связанными с часовыми поясами, в ваших проектах. Помните, что цель состоит в том, чтобы создавать приложения, которые будут бесперебойно работать для пользователей, независимо от их географического местоположения.

Давайте продолжим обсуждение в разделе комментариев ниже. Мне бы хотелось услышать о вашем опыте работы с часовыми поясами, о любых проблемах, с которыми вы столкнулись, или об альтернативных подходах, которые вы сочли эффективными. Ваша информация может оказаться чрезвычайно ценной для меня и других читателей, сталкивающихся с аналогичными проблемами.

Спасибо за чтение, и я надеюсь, что эта статья окажется полезной на вашем пути развития. Давайте продолжать учиться и совершенствоваться вместе! ?

Чтение ссылок

• Часовой пояс
• Что такое часовой пояс?
• Как управлять часовыми поясами и синхронизировать ваше программное обеспечение с международными клиентами
• Работа с часовыми поясами в веб-разработке
• Работа с датами и временем в Go: обработка часовых поясов и форматирование