|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Igor Dzyu 2:5020/400 13 Apr 2005 08:45:24
To : Sergej Pupykin
Subject : Re: ntpd и 2036 год
--------------------------------------------------------------------------------
"Sergej Pupykin" <sergej.pupykin@lx.intercon.ru> сообщил/сообщила в новостях
следующее: news:m33btx6klp.fsf@fserver.internal.lx.intercon.ru...
>
> Hi, All!
>
> Hе подскажет ли кто, зачем с некоторых пор у моего ntpd reference time
> стало Feb 7 2036 9:28:16?
>
> Причем не только у меня. Поиск в гугле по ключевым словам "ntpd Feb 7
> 2036" ничего толкового не дает (я не нашел). Только описания кучи таких же
> проблем и предложения подождать, мож само рассосется.
>
> Hа сервере время нормальное стоит
> # date
> Tue Apr 12 01:55:59 MSD 2005
>
> А клиенты говорят, что разница во времени слишком большая и предлагают
> сначала синхронизировать руками до точности более чем +-30 лет ж-)
почитал инфы, как я понял сам NTP протокол версии 3 будет работать до 2036
года по
по RFC 1305
по RFC 2030 http://www.alllinuxinfo.com/rfc/show/2030.html
использование NTP версии 4 продлит работу до 2104 года
возможно у тебя используется протокол версии 4 или на той стороне он юзается
попробуй выдать команду
ntpdate -o 3 195.2.64.5
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that the
64-bit field will overflow some time in 2036 (second 4,294,967,296).
Should NTP or SNTP be in use in 2036, some external means will be
necessary to qualify time relative to 1900 and time relative to 2036
(and other multiples of 136 years). There will exist a 200-picosecond
interval, henceforth ignored, every 136 years when the 64-bit field
will be 0, which by convention is interpreted as an invalid or
unavailable timestamp.
As the NTP timestamp format has been in use for the last 17 years,
it remains a possibility that it will be in use 40 years from now
when the seconds field overflows. As it is probably inappropriate
to archive NTP timestamps before bit 0 was set in 1968, a
convenient way to extend the useful life of NTP timestamps is the
following convention: If bit 0 is set, the UTC time is in the
range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
January 1900. If bit 0 is not set, the time is in the range 2036-
2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
2036. Note that when calculating the correspondence, 2000 is not a
leap year. Note also that leap seconds are not counted in the
reckoning.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
