Форум PHP

почему mktime(0,0,0,1,1,1970) = -10800?
откуда взялось отрицательное число? Разве не ноль должен вернуться?

date_default_timezone_get() - говорит, что временная зона Европа/Москва.

----
ну и заодно спрошу: как в unix timestamp заменить год, оставив дату на месте? (можно, например, добавить или отнять кол-во секунд за целый год, но как быть в этом случае с високосным годом?).

>почему mktime(0,0,0,1,1,1970) = -10800?
>откуда взялось отрицательное число? Разве не ноль должен вернуться?
>date_default_timezone_get() - говорит, что временная зона Европа/Москва.

Вот потому что Москва - поэтому и не ноль. -10800 это три часа разницы.
смотрите определение unix timestamp .

>ну и заодно спрошу: как в unix timestamp заменить год, оставив дату на месте? (можно, например, добавить или отнять кол-во секунд за целый год, но как быть в этом случае с високосным годом?).

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

Trianon, а в каких случаях вообще используется этот таймштам с его гемороями и ограничениями? Кому он такой сдался то?

У него нет никакого геморроя.
Таймштамп это линейное время в котором хорошо и удобно фиксировать абсолютные моменты и представлять интервалы. Внутри программы.
А к примеру ISO-строка (YYYY-MM-DD HH:MM:SS) - это вид представления времени, в котором те же моменты удобно показывать человеку.

Что касается ограничений, тут увы да...
Но они, полагаю, относительно скоро исчезнут. С переходом на 64битную архитектуру.

мда на эту архитектуру уже лет двадцать переходят - переходят, да всё никак передут, к слову как и на HyperThreading…

Хорошо. Вот я храню в unix timestamp интервалы - мне интересны месяц/день. Интервалы эти сравниваются с интервалом, который вводит пользователь. На ваш взгляд я выбрал удачный формат для хранения? Или же лучше timestamp который в mysql (YYYY-MM-DD HH:MM:SS)?

Вопрос этот меня волнует в том смысле, что пока не представляю какого плана геморои могут свалиться на голову из-за неправильного выбора формата хранения интервалов. Ну, скажем, как я понял - могут возникнуть проблемы если измениться хостинг.

timestamp который в MySQL хранится точно также - в виде числа секунд.
Это MySQL его преобразует перед тем, как поместить в поле записи, и после того, как извлечь оттуда.
Преобразует согласно той таймзоны, которая установлена на сервере MySQL по умолчанию.
Что вобщем-то может не совпадать с таймзоной пользователя ( как, впрочем, и заданная таймзона php)

Какие Вас подстерегают неприятности - сказать трудно. :)

>timestamp который в MySQL хранится точно также - в виде числа секунд.

Так, значит то, что в phpmyadmin выводится в человеческом формате - это всего лишь ширма? А я то, наивный, полагал что все данные там отображаются как есть. Ну или насколько возможно к настоящему представлению.

>Преобразует согласно той таймзоны, которая установлена на сервере MySQL по умолчанию.
>Какие Вас подстерегают неприятности - сказать трудно. :)

Так вот это и настораживает. Я пока не совсем понял; как поведет себя код, окажись он на сервере в какой-нибудь Австралии. Конечно, такое развитие событий маловероятно - но знать надо бы.

А как сейчас ведет себя код, к которому обращаются одновременно из, допустим, Владивостока, Калининграда и Екатеринбурга, Вас не настораживает?

phpMyAdmin честно выдает то, что отдал ему сервер MySQL.
Сервер же уже всё переделал перед тем как отдать, так что PMA может с этим сделать?

phpMyAdmin честно выдает то, что отдал ему сервер MySQL.
Сервер же уже всё переделал перед тем как отдать, так что PMA может с этим сделать?

Ааа. Вспомнил,так в некоторых других языках время тоже в 32битном формате храниться, только, как помню, без привязки к "эпохам". А тут получается формат один, но mktime выдает с привязкой к гринвичу, а mysql - нет. Вроде так.

>А как сейчас ведет себя код, к которому обращаются одновременно из, допустим, Владивостока, Калининграда и Екатеринбурга, Вас не настораживает?

уу, запахло керосином. Вообще-то, пока не проверял. Неужели, это ТО самое? :)
Я мыслю пока так: если код работает у "меня" на серваке, то откуда бы к нему не обращались - проблем с датами unix timestamp возникнуть не должно. Или я не прав?

Да, по идее разницы в работе не должно быть - у меня то важны только день/месяц, время - пофиг. Понимаю, что это скорее отмазка, но ничего лучше я пока не придумал.

Что значит - у "меня" на серваке?

>Что значит - у "меня" на серваке?

у хостера, в мск. потому и в кавычках.

Какая разница, где Вы живете?
Вы работатете в Москве. Сайт работает. Всё в порядке.
Вы проводите отпуск (в Болгарии к примеру) .
Сайт что сам собой от ревности сломается?

>Какая разница, где Вы живете?
>Вы работатете в Москве. Сайт работает. Всё в порядке.
>Вы проводите отпуск (в Болгарии к примеру) .
>Сайт что сам собой от ревности сломается?

Да хрен поймешь его. Но по вашим словам - страхов при использовании unx-timestamp не должно быть.

Кстати, анекдот про болгарина и учительницу знаете?

>Да хрен поймешь его. Но по вашим словам - страхов при использовании unx-timestamp не должно быть.

Я этого не говорил. Я лишь сказал, что мне трудно судить, что именно у Вас может создать трудности.

>Кстати, анекдот про болгарина и учительницу знаете?
(кивнув головой)
Нет. Знаю только стишок, неприличный настолько, что цитировать здесь не рискну.