PHP 2038

в 2к+18 году

на 32-битках

Nuff said.

Nuff said.

Будто что-то плохое.

PHP гоняют на серверах, сервера давно все адекватные люди перевели на 64 битный линукс, проблемы нет

Будто что-то плохое.

Не то, чтобы плохое — бессмысленное.

64-битные системы в массах уже больше десяти лет. Некоторые дистрибутивы уже даже перестали поддерживать 32-битные версии.

PHP гоняют на серверах, сервера давно все адекватные люди перевели на 64 битный линукс, проблемы нет

Как будто в 2к+18 уже нельзя пыхнуть на каком-нибудь роутере.

64-битные системы в массах уже больше десяти лет. Некоторые дистрибутивы уже даже перестали поддерживать 32-битные версии.

Тогда можно было бы просто запилить 64 bit time_t для всех платформ.

до 2038-го роутеры 100500 раз успеют запланированно устареть разными способами, к тому времени они тоже 64 битные будут :)

до 2038-го роутеры 100500 раз успеют запланированно устареть разными способами, к тому времени они тоже 64 битные будут :)

Но ведь расчёты в будущее и прочие манипуляции с датами можно делать уже сейчас.

Ну потому что проблема уровнем ниже, и решать её в том же пых-пыхе не имеет смысла

например, какие?

вот, к примеру, сертификат для HTTPS дальше 2038 года ты не сможешь сейчас выписать, в формате 32 бита на timestamp

Так всё работает же:

<?php

$dt = DateTime::createFromFormat('Y.m.d', '2439.01.01');
$dt->add(new DateInterval('P31Y'));
echo $dt->format('Y.m.d') . PHP_EOL;

~$ php test.php 
2470.01.01

~$ uname -a
Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) i686 GNU/Linux

~$ php -v
PHP 5.6.30-0+deb8u1 (cli) (built: Feb  8 2017 09:49:20) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

А, я понял с чего.

Ты с какой пещеры вылез что дату время в таймстампе хранишь? В БД тоже так? Ну ССЗБ тогда.

Ну да, там давно уже ввели DateTime

Ну и пример у меня на 32 битной машинке.

например, какие?

Здравствуйте, я Маша, родилась <?= $birth = '26.04.1986'; ?> г. У меня две головы и три руки. <?= $date='26.04.2046'; ?> г. мне исполнится <?= ($utime = strtotime($date)) - strtotime($birth); ?> секунд, это будет <?= date('N', $utime); ?> день недели.

Так всё работает же:

Например, запустил https://github.com/solarissmoke/php-moon-phase/blob/master/Solaris/MoonPhase.php
Нет, не работает.

DateTime::

А зачем переписывать на DateTime если можно не переписывать?

Ну потому что проблема уровнем ниже, и решать её в том же пых-пыхе не имеет смысла

Ну вот что-то пилят: http://adodb.org/dokuwiki/doku.php?id=v5:datetime:datetime_index
Но там не все функции.

Не нужно

Писец. Я понимаю что таймстамп переполняется.

Как зачем переписывать? Затем чтобы работало.

Но если очень хочется дрочить секундочки дальше и на 32 битах — используй http://php.net/manual/ru/book.gmp.php

Существует большая степень вероятности того, что к 2038 году все функционирующие системы и PHP-интерпретаторы будут 64-битные. Такое изменение даст возможность беспрепятственно работать с датой примерно на 290 миллиардов лет вперёд.

<?=

Дальше не читал.

Дальше не читал.

Уснул, читая мануал к PHP 5.4? Ничего, ляг поспи и всё пройдёт.

Почему тогда не 5.1, например, или еще чего постарше?

P.S. посоветуйте редис, только чтоб не ограничиваться объемом ram. ssdb? ledis? В memcachedb смотрю 10 лет коммитов не было.

Почему тогда не 5.1, например, или еще чего постарше?

Потому что с 5.4

Тег <?= доступен всегда, вне зависимости от настройки short_open_tag.

<?=

- быдлостиль, надеюсь его выпилят в 7.x рано или поздно.

- быдлостиль, надеюсь его выпилят в 7.x рано или поздно.

Зачем его выпиливать и чем <?php echo … лучше?

Под фряхой встречал был не доступен. Так что и палка раз в год стреляет.

PHP и прочих питоноперлов

Это называется «пыхоплеяда». Учимся говорить правильно.

у хипсторов

У дегенератов.

у хипсторов

У дегенератов.

Как будто есть разница.

и чем <?php echo … лучше?

Явным пониманием, что это именно пых-пых. Не?

Явным пониманием, что это именно пых-пых. Не?

Ну если ты сам не знаешь на каком языке пишешь и без явного указания К.О. обойтись не можешь — тогда да.

Ну если ты сам не знаешь

Мне по барабану. Вообще бы PHP не было - было бы ещё лучше. :-) А вот анализаторам несколько сложнее.

Ну потому что проблема уровнем ниже, и решать её в том же пых-пыхе не имеет смысла

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

Вообще бы PHP не было - было бы ещё лучше.

Кому лучше? Ты всегда можешь просто не использовать PHP.

А вот анализаторам несколько сложнее.

Как будто неиспользование кем-либо <?= повлияет на сложность анализатора.

вот помню у меня был php на восьмибитке - вот там да, были проблемы так проблемы!