Как сохранить метки времени в Social Media Unix в Postgres, сохраняя местное время пользователя - PullRequest
0 голосов
/ 26 апреля 2018

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

По сути, у нас есть база данных Postgres, где мы храним различные сообщения в социальных сетях (Foursquare, Flickr и т. д.) для анализа.API обычно возвращают метки времени Unix, , насколько я знаю, всегда UTC .

Проблема в том, что когда мы анализируем эти данные, нас не волнует UTC,нам нужно знать местное время пользователя, когда он / она публикуется в социальных сетях.Предположим, например, что кто-то сфотографировал оперный театр в Сиднее в 16:00 по местному времени в Сиднее (GMT + 10).Как мы храним это в Postgres - timestamp with timezone или timestamp without timezone?Доступно ли местное время пользователя вообще, или мы должны принимать во внимание геокоординаты (если таковые имеются) для расчета местного времени пользователя?

Суммировано:

  • нас не волнует время, в течение которого аналитик / следователь просматривает данные в Postgres
  • нас не волнует смещение кUTC / GMT , было бы неплохо иметь его (знать общее местоположение), но это не очень важно
  • мы заботимся только о субъективном, личном времени, которое пользователь воспринимает, когдаотправка / фотографирование

Как лучше всего хранить метаданные с учетом этих обстоятельств?

[Править] Я сделал запрос, чтобы узнать, где пользователи упоминают «о»часы »в своих сообщениях, чтобы сравнить это с post_publish_date (метка времени без часового пояса), как возвращено из API).Удивительно, но то, что я вижу, предполагает, что все эти временные метки являются местным временем, а не UTC:

"post_publish_date","post_body"
"2016-12-06 07:27:07","[...] at 8 o'clock a.m. [...]"
"2018-02-22 05:21:53","[...] main 6 o'clock road to [...]"
"2018-01-27 06:13:04","[...] get up early otherwise you miss [...] 6 o'clock [...]"
"2018-02-09 16:21:37","It's Friday [...] its gotta be 5 o'clock [...]"
"2018-02-02 15:44:21","It's Friday, [...] it's always 5 o'clock [...]"
"2015-11-21 02:37:53","[...] until 4 o'clock in the morning. [...]"
"2017-09-15 07:51:53","[...] 9 o'clock at night[...]"
"2017-12-18 19:52:40","[...]Date: ♨18.12.2017  [...] 20o'clock [...] Location: New York[...]"

Это отличный пост , который объясняет различия, но говорится, что метка времени Unix может быть в любом часовом поясе - UTC или по местному времени , и никто не узнает, если не указан часовой пояс.Теперь возникает вопрос: могу ли я хранить сообщения с метками времени без часового пояса в том же столбце (отформатированном как timestamp with timezone), как и те сообщения, для которых указан часовой пояс?

Здесь - другое сообщение, котороеописано, как извлечь время для твитов из соответствующих координат пользователя при твиттере.Следовательно, время, в которое Twitter возвращается на латы, - это время UTC, а не местное время.

1 Ответ

0 голосов
/ 27 апреля 2018

После некоторого тестирования, я думаю, я получил правильный ответ:

Различные службы социальных сетей по-разному обрабатывают метки времени и часовые пояса. Три аспекта времени имеют отношение:

  • (1) местное время пользователя (когда сообщение было создано или опубликовано)
  • (2) абсолютное время по Гринвичу / Гринвичу (количество секунд, прошедших с 1 января 1970 г. по Гринвичу, то же самое, что и время по Гринвичу), что относится, например, к глобальным сравнениям времени.
  • (3) местное время зрителя (например, при просмотре твита в Интернете это предотвращает парадокс просмотра того, что будет опубликовано в будущем)

Пример: (1) Tweet был опубликован в 9:37 в Берлине (+2 CEST), (2) Twitter сохраняет это как 7:37 UTC (+00 ) и (3) при просмотре этого твита в Калифорнии (-7 PT), время, которое пользователь видит, - 0:37 (перевод в местное время зрителя).

Хотя (3) имеет отношение к веб-приложениям, при анализе данных обычно интересует местное время участвующего пользователя, а не метка времени UTC или местное время зрителя. Например, для Flickr и Instagram это время напрямую доступно из API. Для Twitter местное время должно быть рассчитано на основе дополнительных критериев, которые иногда доступны .

Что это значит для хранения данных в Postgres?

В postgres есть два варианта: сохранение времени как timestamp without timezone или timestamp with timezone. Однако Postgres никогда не будет хранить информацию о часовом поясе в отметке времени , здесь «часовой пояс» относится только к форматированию отметки времени, когда отображает отметки времени Postgres (3). Поэтому при хранении данных для анализа отметки времени не должны обрабатываться . Они рассматриваются как timestamp without timezone, потому что часовой пояс участвующего пользователя изначально неизвестен (без учета дополнительной информации). Для некоторых служб, таких как Twitter, аналитик должен перевести это время в местное время пользователя перед анализом (например, с учетом utc_offset, местоположения сообщения, языка или других атрибутов).

...