FishHookЯ разобрался (за отдельный день :) ), надо было понять принцип. Но главное, что они дают задавать года туда и обратно за пределы всяких 1900-х годов. Это происходит за счёт хранения времени в миллисекундах в 64-битном целочисленном типе. Дата ограничена, конечно, но десятки тысяч лет спокойно даёт задавать.
Донельзя идиотские
Полная версия: Стоит ли читать "Fluent Python" после Лутца?
py.user.nextВот прям на Юлианский календарь переходит?
Но главное, что они дают задавать года туда и обратно за пределы всяких 1900-х годов.
py.user.nextДа там не в чем разбираться. А ты попробуй практическую задачу решить, например отобразить дату в другой таймзоне. Проще сразу подключить moment.
Я разобрался (за отдельный день)
FishHookЗачем? Он хранит миллисекунды и заглядывает туда, где ещё не было календарей. А ты предлагаешь, чтобы оно распечатывало строку в клинописи или вообще рисовало солнечные часы в консоли? По миллисекундам ты можешь дату точно вычислить в любом календаре в обратную сторону от его появления - в этом и фишка миллисекунд.
Вот прям на Юлианский календарь переходит?
FishHookВремя хранится в UTC. И там есть методы типа getHours() и getUTCHours().
А ты попробуй практическую задачу решить, например отобразить дату в другой таймзоне.
> var d = new Date()
undefined
> d
2017-10-10T09:17:19.716Z
> String(d)
'Tue Oct 10 2017 20:17:19 GMT+1100 (+11)'
> d.getHours()
20
> d.getUTCHours()
9
>
py.user.next
Слушай, задача же элементарна - отобразить текущие время и дату в разных таймзонах. Ты можешь это сделать или нет?
Слушай, задача же элементарна - отобразить текущие время и дату в разных таймзонах. Ты можешь это сделать или нет?
Он хранит миллисекунды и заглядывает туда, где ещё не было календарейНу и какая конкретно дата и время были в Москве 131400000000 миллисекунд назад?
FishHook
отобразить текущие время и дату в разных таймзонах
> var d = new Date();
undefined
> var o = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
... 11, 12, 13, 14, 15, 16, 17, 18, 19,
... 20, 21, 22, 23]
undefined
>
> var r = o.map(function(i) {
... return new Date(d.getTime() + (i * 3600000));
... });
undefined
>
> d
2017-10-10T10:26:14.832Z
> r
[ 2017-10-10T10:26:14.832Z,
2017-10-10T11:26:14.832Z,
2017-10-10T12:26:14.832Z,
2017-10-10T13:26:14.832Z,
2017-10-10T14:26:14.832Z,
2017-10-10T15:26:14.832Z,
2017-10-10T16:26:14.832Z,
2017-10-10T17:26:14.832Z,
2017-10-10T18:26:14.832Z,
2017-10-10T19:26:14.832Z,
2017-10-10T20:26:14.832Z,
2017-10-10T21:26:14.832Z,
2017-10-10T22:26:14.832Z,
2017-10-10T23:26:14.832Z,
2017-10-11T00:26:14.832Z,
2017-10-11T01:26:14.832Z,
2017-10-11T02:26:14.832Z,
2017-10-11T03:26:14.832Z,
2017-10-11T04:26:14.832Z,
2017-10-11T05:26:14.832Z,
2017-10-11T06:26:14.832Z,
2017-10-11T07:26:14.832Z,
2017-10-11T08:26:14.832Z,
2017-10-11T09:26:14.832Z ]
>
FishHook
были в Москве 131400000000 миллисекунд назад
> var d = new Date()
undefined
> var r = new Date(d.getTime() - 131400000000 + 3 * 3600000)
undefined
>
> d
2017-10-10T10:34:24.065Z
> r
2013-08-11T17:34:24.065Z
>
py.user.next
Оба ответа не верны.
Оба ответа не верны.
FishHookОба ответа верны.
Оба ответа не верны.
Объясняю.
1.
Что происходит на практике. Есть предприятие-заказчик в Якутии. Есть техподдержка в Москве. Техподдержка желает видеть всю ту же информацию, что и пользователь, для этого логинится под Якутией, на сервере активируется таймзона Asia/Yakutsk и казалось бы все зашибись. Но дурацкие даты в ЖС не понимают таймзоны в конструкторе, либо таймстамп, либо таймтупл. Поэтому в каком формате ты не передавай дату с сервера, ЖС создаст дату в таймзоне браузера. Это уже само по себе очень не хорошо. Но теперь мне надо заняться переводом московского времени в якутское! Вот больше делать нефиг. Но и хрен бы с ним, но если я поступлю по твоей методе, просто возьму и прихреначу пару часов к дате, то я получу другое время (не время в таймзоне Якутии, а другое), что означает: если работник техподдержки изменит, например, начало смены на полчаса и отправит исправленный вариант на сервер, сервер получит неправильное время, либо придется заниматься какими-то преобразованиями до отправки. Если мы используем какую-то библиотеку контролов, последнее испытание превращается в тот еще квест, а если на машине пользователя таймзона выставлена неправильно (человек часто ездит в командировки) то работа со временем в браузере становится нереальной.
Всё, что нужно для исправления ситуации, это добавить поддержку таймзон в дату. Но этого нет, поэтому даты в ЖС идиотские.
2.
Ошибка №2 в том, что часовой пояс - это не смещение времени. Это смещение времени, привязанное к географическим координатам и времени абсолютному. Внезапно, отняв или прибавив N миллисекунд к дате, мы можем получить значение не существовавшее в Якутии, потому что попадем на час, выпавший из истории в момент перевода часов на летнее время. Если ты думаешь, что на этом нельзя потерять солидно денежек, ты ошибаешься.
3.
Ты ошибся на три часа!
1.
Он хранит миллисекундыВеликолепно, пусть хранит. Вопрос: в Кемерово сейчас 9:43, а в Москве 5:43. Количество миллисекунд, с начала эпохи в Москве и в Кемерово прошло одинаковое количество? Разумеется. Это одно и то же время, только выглядит для пользователя по-разному. Поэтому, когда для отображения времени в разных таймзонах, ты изменяешь количество миллисекунд, ты совершаешь ошибку, ты буквально изменяешь время, о чем тебя не просили.
Что происходит на практике. Есть предприятие-заказчик в Якутии. Есть техподдержка в Москве. Техподдержка желает видеть всю ту же информацию, что и пользователь, для этого логинится под Якутией, на сервере активируется таймзона Asia/Yakutsk и казалось бы все зашибись. Но дурацкие даты в ЖС не понимают таймзоны в конструкторе, либо таймстамп, либо таймтупл. Поэтому в каком формате ты не передавай дату с сервера, ЖС создаст дату в таймзоне браузера. Это уже само по себе очень не хорошо. Но теперь мне надо заняться переводом московского времени в якутское! Вот больше делать нефиг. Но и хрен бы с ним, но если я поступлю по твоей методе, просто возьму и прихреначу пару часов к дате, то я получу другое время (не время в таймзоне Якутии, а другое), что означает: если работник техподдержки изменит, например, начало смены на полчаса и отправит исправленный вариант на сервер, сервер получит неправильное время, либо придется заниматься какими-то преобразованиями до отправки. Если мы используем какую-то библиотеку контролов, последнее испытание превращается в тот еще квест, а если на машине пользователя таймзона выставлена неправильно (человек часто ездит в командировки) то работа со временем в браузере становится нереальной.
Всё, что нужно для исправления ситуации, это добавить поддержку таймзон в дату. Но этого нет, поэтому даты в ЖС идиотские.
2.
Ошибка №2 в том, что часовой пояс - это не смещение времени. Это смещение времени, привязанное к географическим координатам и времени абсолютному. Внезапно, отняв или прибавив N миллисекунд к дате, мы можем получить значение не существовавшее в Якутии, потому что попадем на час, выпавший из истории в момент перевода часов на летнее время. Если ты думаешь, что на этом нельзя потерять солидно денежек, ты ошибаешься.
3.
import pytz import datetime now = datetime.datetime.utcnow().replace(tzinfo=pytz.UTC).astimezone(pytz.timezone("Europe/Moscow")) long_time_ago = now - datetime.timedelta(milliseconds=131400000000) print(long_time_ago) >>>2013-08-12 10:27:54.401089+03:00
var d = new Date() var r = new Date(d.getTime() - 131400000000 + 3 * 3600000) >>>Mon Aug 12 2013 17:28:19 GMT+0700 (+07)
Ты ошибся на три часа!