ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Почему
11 сообщений из 11, страница 1 из 1
Почему
    #39606986
andrey10
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey10
Гость
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
mysql> select FROM_UNIXTIME(unix_timestamp('2011-01-01 09:00:00') + 525600 * 60);
+--------------------------------------------------------------------+
| FROM_UNIXTIME(unix_timestamp('2011-01-01 09:00:00') + 525600 * 60) |
+--------------------------------------------------------------------+
| 2012-01-01 10:00:00                                                |
+--------------------------------------------------------------------+
1 row in set

mysql> select '2011-01-01 09:00:00' + interval 525600 minute;
+------------------------------------------------+
| '2011-01-01 09:00:00' + interval 525600 minute |
+------------------------------------------------+
| 2012-01-01 09:00:00                            |
+------------------------------------------------+
1 row in set



Почему в первом варианте получается на час больше?
...
Рейтинг: 0 / 0
25.02.2018, 16:49
| Ответить | Цитировать | Написать  
Почему
    #39606988
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
andrey10,

Какой системный часовой пояс? Зимнее/летнее время включено?
...
Рейтинг: 0 / 0
25.02.2018, 16:55
| Ответить | Цитировать | Написать  
Почему
    #39606991
andrey10
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey10
Гость
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
mysql> show variables like '%time%';
+---------------------------------------+-------------------+
| Variable_name                         | Value             |
+---------------------------------------+-------------------+
| connect_timeout                       | 10                |
| datetime_format                       | %Y-%m-%d %H:%i:%s |
| delayed_insert_timeout                | 300               |
| flush_time                            | 0                 |
| have_response_time_distribution       | YES               |
| innodb_lock_wait_timeout              | 50                |
| innodb_old_blocks_time                | 0                 |
| innodb_rollback_on_timeout            | OFF               |
| innodb_thread_concurrency_timer_based | OFF               |
| interactive_timeout                   | 28800             |
| lc_time_names                         | en_US             |
| lock_wait_timeout                     | 31536000          |
| long_query_time                       | 2.000000          |
| net_read_timeout                      | 60                |
| net_write_timeout                     | 60                |
| query_response_time_range_base        | 10                |
| query_response_time_stats             | OFF               |
| slave_net_timeout                     | 3600              |
| slow_launch_time                      | 2                 |
| slow_query_log_always_write_time      | 10.000000         |
| slow_query_log_timestamp_always       | OFF               |
| slow_query_log_timestamp_precision    | second            |
| system_time_zone                      | MSK               |
| thread_pool_idle_timeout              | 60                |
| time_format                           | %H:%i:%s          |
| time_zone                             | SYSTEM            |
| timed_mutexes                         | OFF               |
| timestamp                             | 1519568045        |
| wait_timeout                          | 28800             |
+---------------------------------------+-------------------+
...
Рейтинг: 0 / 0
25.02.2018, 17:16
| Ответить | Цитировать | Написать  
Почему
    #39606992
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Случаем, не в 2011 году отменили переход на зимнее/летнее время?

Аналогичный эффект с другими годами повторяется?
...
Рейтинг: 0 / 0
25.02.2018, 17:19
| Ответить | Цитировать | Написать  
Почему
    #39606993
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
https://ru.wikipedia.org/wiki/Время_в_России сезонный перевод часов отменён в 2011 году
...
В соответствии с действующим на тот момент постановлением от 8 января 1992 года, в последнее воскресенье марта (27 марта 2011 года) часы были переведены на 1 час вперёд, но осенний перевод часов назад отменялся. Похоже, что из-за этого.
Т.е. фактически 2011 год был на час короче в России.
...
Рейтинг: 0 / 0
25.02.2018, 17:24
| Ответить | Цитировать | Написать  
Почему
    #39606995
andrey10
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey10
Гость
Ясно, спасибо, но тогда почему "+ interval" не учитывает этого?
...
Рейтинг: 0 / 0
25.02.2018, 17:29
| Ответить | Цитировать | Написать  
Почему
    #39606997
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
andrey10почему "+ interval" не учитывает этого? https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-add
В описании функции ни слова не говорится о часовых поясах. Похоже, что она их не использует.
...
Рейтинг: 0 / 0
25.02.2018, 17:32
| Ответить | Цитировать | Написать  
Почему
    #39606999
andrey10
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey10
Гость
Понял, благодарю.
...
Рейтинг: 0 / 0
25.02.2018, 17:40
| Ответить | Цитировать | Написать  
Почему
    #39607060
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkle
Участник
miksoftandrey10почему "+ interval" не учитывает этого? https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-add
В описании функции ни слова не говорится о часовых поясах. Похоже, что она их не использует.ИМХО таки использует. Попробую пояснить, почему я так считаю. В примере буду использовать 2016 год.

На моем компе системной установлена самарская таймзона (МСК+1). Живу то я в Самаре.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
MariaDB [mysql]> SELECT @@global.time_zone, @@session.time_zone;                           
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+
1 row in set (0.00 sec)

MariaDB [mysql]> SELECT FROM_UNIXTIME(unix_timestamp('2016-01-01 09:00:00') + 525600 * 60);
+--------------------------------------------------------------------+
| FROM_UNIXTIME(unix_timestamp('2016-01-01 09:00:00') + 525600 * 60) |
+--------------------------------------------------------------------+
| 2016-12-31 09:00:00                                                |
+--------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [mysql]> SELECT '2016-01-01 09:00:00' + interval 525600 minute;
+------------------------------------------------+
| '2016-01-01 09:00:00' + interval 525600 minute |
+------------------------------------------------+
| 2016-12-31 09:00:00                            |
+------------------------------------------------+
1 row in set (0.00 sec)

Тут всё ровно, никаких катаклизмов у нас не происходило.

4 декабря, в 2 часа ночи соседняя Саратовская область перешла из московского в самарский часовой пояс (МСК+1). Крутнули стрелки на час вперед, укоротив себе зимнюю ночь.
Не зная об этом факте я изволил опоздать, полагая, что у меня ещё есть в запасе немного времени.

Тот же тест на другой таймзоне.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
MariaDB [mysql]> SET time_zone = 'Europe/Saratov';
Query OK, 0 rows affected (0.00 sec)

MariaDB [mysql]> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | Europe/Saratov      |
+--------------------+---------------------+
1 row in set (0.00 sec)

MariaDB [mysql]> SELECT FROM_UNIXTIME(unix_timestamp('2016-01-01 09:00:00') + 525600 * 60);
+--------------------------------------------------------------------+
| FROM_UNIXTIME(unix_timestamp('2016-01-01 09:00:00') + 525600 * 60) |
+--------------------------------------------------------------------+
| 2016-12-31 10:00:00                                                |
+--------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [mysql]> SELECT '2016-01-01 09:00:00' + interval 525600 minute;
+------------------------------------------------+
| '2016-01-01 09:00:00' + interval 525600 minute |
+------------------------------------------------+
| 2016-12-31 09:00:00                            |
+------------------------------------------------+
1 row in set (0.00 sec)

Тут INTERVAL как раз учел переход Саратовской области из одного часового пояса в другой и показал правильно местное время в используемой таймзоне Europe/Saratov .
А что показывает простое суммирование секунд - погоду на Марсе? Не, это и не московское время (там восемь утра) из старого часового пояса. Не понятно сходу, где и как можно такой результат использовать.

Длинновато получилось и занудно. Ну, время - штука тонкая и не всегда сразу понятная. :-)
...
Рейтинг: 0 / 0
26.02.2018, 01:11
| Ответить | Цитировать | Написать  
Почему
    #39607063
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
vkle
Код: sql
1.
2.
3.
4.
5.
6.
7.
MariaDB [mysql]> SELECT '2016-01-01 09:00:00' + interval 525600 minute;
+------------------------------------------------+
| '2016-01-01 09:00:00' + interval 525600 minute |
+------------------------------------------------+
| 2016-12-31 09:00:00                            |
+------------------------------------------------+
1 row in set (0.00 sec)


Тут INTERVAL как раз учел переход Саратовской области из одного часового пояса в другойХм, не вижу что и где он учел. Как было 9 часов утра, так и осталось. А 525600 - это целое количество суток. Т.е. никакого сдвига на час нет, просто арифметическое суммирование.
...
Рейтинг: 0 / 0
26.02.2018, 01:46
| Ответить | Цитировать | Написать  
Почему
    #39607066
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkle
Участник
miksoft525600 - это целое количество сутокДавайте уточним.
525600 - это целое количество суток, каждые из которых имеют ровно 24 часа . Так?

Момент, на который я обращаю внимание: 4 декабря 2016 года сутки в "Europe/Saratov" были короче - вместо 24 часов там было всего лишь 23 часа (стрелки перевели на час вперед). Таким образом, 525600 в данном конкретном случае уже не есть целое количество суток. Нет возражений в этом моменте?

Чтобы получить целое количество суток для данного случая нужно из 525600 вычесть те самые 60 минут, которые были съедены переводом стрелок.

Простое суммирование секунд как раз и не учитывает эти короткие сутки и показывает непонятные десять часов утра.
INTERVAL учитывает короткие сутки и показывает местное время девять часов в соответствии с выбранной таймзоной "Europe/Saratov".

А вот для Самары и многих других 525600 в 2016 году так и осталось целым количеством суток.

Впрочем, я лишь изложил свое понимание механизма расчета времени в соответствии с таймзоной. Возможно, есть какие-то другие, более понятные объяснения.
...
Рейтинг: 0 / 0
26.02.2018, 02:24
| Ответить | Цитировать | Написать  
11 сообщений из 11, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Почему
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]