Как увеличить дату?

[sash-kan]

а ведь вполне возможно, что железяки с 32-битными процессорами могут прожить эти 28 лет.
как обычно, самые эпичные истории будут у кацманавтов.

[watashiwa_daredeska]

а ведь вполне возможно, что железяки с 32-битными процессорами могут прожить эти 28 лет.

Подвинут начало эпохи, в конце концов.

[t.t]

2038-го. Эта проблема не только перевода в секунды касается, она в принципе ещё не решена:

Shell

$ date -d +27years вт май 26 2037 08:29:27 EEST $ date -d +28years date: invalid date `+28years'

У меня работает и +28 лет, и +29, и даже +1 000 000 000 лет. А вот +10 000 000 000 уже не работает.

// Проверил на ноутбуке. Не работает, возможная причина: на ноутбуке 32-битный Celeron, на рабочем компьютере— 64-битный Phenom.

Да, именно в этом причина: это ограничение для 32-битных систем.

[t.t]

а ведь вполне возможно, что железяки с 32-битными процессорами могут прожить эти 28 лет.
как обычно, самые эпичные истории будут у кацманавтов.

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

а ведь вполне возможно, что железяки с 32-битными процессорами могут прожить эти 28 лет.

Подвинут начало эпохи, в конце концов.

А старый софт станет неправильно определять время...

[watashiwa_daredeska]

А старый софт станет неправильно определять время...

Первый раз что-ли? y2k уже проходили, и y2k38 пройдем :)

[drBatty]

Почему сложно сказать? В тех случаях, когда эти два способа покажут разные результаты, правильным будет способ, предоставляемый командой date (days, weeks и т.д.).

потому что иногда интересно узнать возраст чего-то в секундах. а вот все эти days и т.д. дают несколько другое.

А старый софт станет неправильно определять время...

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

[watashiwa_daredeska]

появление файлов созданных завтра. я даже боюсь думать, как к такому отнесётся скажем find...

Нормально отнесется, какая ему-то разница? :)

[dergachev]

Да, воистину! o_O, клёво как.
Действительно не работает на моём нетбуке (то бишь с интелятомом).

появление файлов созданных завтра. я даже боюсь думать, как к такому отнесётся скажем find...

Нормально отнесется, какая ему-то разница? :)

А вот gentoo меня не раз ругала, что у /etc/{init.d,conf.d} или у /etc/rc.conf типа мол modification time in the future. Но ничего, работала при этом. Хотя делал touch на всякий пожарный.

[watashiwa_daredeska]

gentoo меня не раз ругала, что у /etc/{init.d,conf.d} или у /etc/rc.conf типа мол modification time in the future. Но ничего, работала при этом.

Ну, это из разряда проверок на осмысленность (среди прочих security check) — предупреждает, да, но ничего фатального.

[t.t]

Почему сложно сказать? В тех случаях, когда эти два способа покажут разные результаты, правильным будет способ, предоставляемый командой date (days, weeks и т.д.).

потому что иногда интересно узнать возраст чего-то в секундах.

Это совсем другая задача. (:

Понятно, что для получения времени в секундах удобнее получать время в секундах. А для задания смещения удобнее пользоваться человеческими обозначениями.

[drBatty]

предупреждает, да, но ничего фатального.

угу. особенно если какой-то скрипт ищет новые файлы и их бекапит. точнее НЕ бекапит.

Понятно, что для получения времени в секундах удобнее получать время в секундах. А для задания смещения удобнее пользоваться человеческими обозначениями.

ладно, убедили (: