Будет ли *теоретически* работать тоссер и мейлер после той страшной
даты в UNIX когда начнётся отсчёт с 1980 года.
Или это проблема не в коде FTN софта, а в коде ядра UNIX и от нас это
не зависит?
Будет ли *теоретически* работать тоссер и мейлер после тойТоссеру и мейлеру пофиг на это, проблемы будут у софта, который
страшной даты в UNIX когда начнётся отсчёт с 1980 года.
работает с этими датами, и если софт не совсем дебильный, про проблемы начнутся только в 2106 году.
Или это проблема не в коде FTN софта, а в коде ядра UNIX и от насПроблема в формате баз данных сообщений, где под дату выделили 4
это не зависит?
байта, и больше туда никак не записать.
Или это проблема не в коде FTN софта, а в коде ядра UNIX и от
нас это не зависит?
Проблема в формате баз данных сообщений, где под дату выделили 4Т.е. как решение можно просто сменить БД?
байта, и больше туда никак не записать.
Или это проблема не в коде FTN софта, а в коде ядра UNIX и от
нас это не зависит?
Проблема в формате баз данных сообщений, где под дату выделили 4
байта, и больше туда никак не записать.
Т.е. как решение можно просто сменить БД?Можно, вот только на что? Придётся ещё и вместо PKT какой-то формат разрабатывать и массово на него переходить.
Самое простое решение проблемы - писать 64-битный unixtime
в
какой-нибудь кладж и научить софт с ним работать. о это всё будет актуально только через 80+ лет, вряд ли фидо к тому времени ещё будет функционировать.
Можно, вот только на что? Придётся ещё и вместо PKT какой-тоПонятненько, как раз об этом и думал, что нужно просто сделать его 64 битным.
формат разрабатывать и массово на него переходить. Самое простое
решение проблемы - писать 64-битный unixtime
Принятно, огромнеёшее спасибо за разъяснения, думал что эта дата
оочень близко. 2035-2045 вроде)
Можно, вот только на что? Придётся ещё и вместо PKT какой-то
формат разрабатывать и массово на него переходить. Самое простое
решение проблемы - писать 64-битный unixtime
Понятненько, как раз об этом и думал, что нужно просто сделатьПросто сделать - не достаточно.
его 64 битным.
Принятно, огромнеёшее спасибо за разъяснения, думал что эта датаВ 2038-м сломается софт, который испоьзует long вместо ulong под юникстайм. о сломается не сильно, прото будет некорректно дату
оочень близко. 2035-2045 вроде)
отображать.
Ато. В сквише из-за ДОСовских APIев ваще секунды все только чётные, и никаво не запаривает, зато проблему юниксового времени чуть должен переживёт.
Принятно, огромнеёшее спасибо за разъяснения, думал что эта дата
оочень близко. 2035-2045 вроде)
В 2038-м сломается софт, который испоьзует long вместо ulong подВаще-то time_t очень даже platform-specific, и если хочешь его,
юникстайм. о сломается не сильно, прото будет некорректно дату
отображать.
например, печатать, то расширяй до long long и как %lld печатай.
| Sysop: | Angel Ripoll |
|---|---|
| Location: | Madrid, Spain |
| Users: | 11 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 43:33:15 |
| Calls: | 302 |
| Calls today: | 2 |
| Files: | 2,759 |
| Messages: | 60,998 |