AP
с date() это не актуально
Зато актуально то, что эта функция делает под капотом, когда кодишь на пыхе, иногда стоит залезать в её исходники
Size: a a a
2020 August 13
NM
Зато актуально то, что эта функция делает под капотом, когда кодишь на пыхе, иногда стоит залезать в её исходники
А что там не так и почему сервис лучше?
C
что же она делает под капотом?
AP
В сервисе тоже есть такой вызов, но она делает syscall чтобы взять время ядра, потом она не не учитывает часовой пояс сайта
AP
цифры друпала
Меня удивляет такое отношение, выходит, что если в Д есть медленный код, то можно всё остальное гоанокодить? Либо нет понимания, когда нужно затыкать железом вместо разработчиков...
C
ты бред написал про date, не надо стрелки переводить
C
Что то я не понял... а как получить список терминов в views у которых нет родителей. Т.е первый уровень?
родитель = 0
AP
ты бред написал про date, не надо стрелки переводить
Это не бред, а причина появления Request_time в 7ке и сервиса в 8ке
C
date - форматирует, Request_time - timestamp, какая тут связь?
AP
Форматирует, если передан 2й аргумент, иначе останавливает пых, лезет в ядро, получает конкурентный доступ к высокоточному таймеру, дожидается возможности оживить пых процесс, восстанавливает контест процесса и только тогда форматирует
AP
Но и форматирует без учёта часового пояса сайта, юзера и прочих настроек(
C
с учётом
AP
с учётом
С чего это? Без второго аргумента даже метка времени будет новая
C
Потому что друпал делает date_default_timezone_set
C
Без учёта есть gmdate
AP
Потому что друпал делает date_default_timezone_set
Начиная с 8.8 эта оптимизация добавлена, но не без багов
C
date_default_timezone_set ещё в семёрке появился
C
там про drupal_get_user_timezone, а не про date_default_timezone_set