Ada_Ru форум

Обсуждение языка Ада

Time

Оставить новое сообщение

Сообщения

Olga Dolbilina
Time
2004-02-23 18:20:24

Доброе время суток!

Поздравляю всех мужчин - участников конференции с Днем защитника Отечества!

 

Наблюдается такая ситуация

 

-- Задаем дату 31.10.2004.

Date := Ada.Calendar.Time_Of (2004, 10, 31, 0.0);

 

-- Прибавляем сутки, ожидая получить 01.11.2004

Date := Date + Ada.Calendar.Day_Duration'Last;

 

-- Получаем день, месяц.

Day := Ada.Calendar.Day (Date);

Month := Ada.Calendar.Month (Date);

...

Получается опять 31.10.2004.

 

Впрочем, если

Date := Date + (Day_Duration'Last + 3601.0);

 

то получим 01.11.2004.

Такой "эффект" наблюдается только для високосных годов.

 

Что это? Компенсация за "високосность"? И почему именно на последнее число октября?

 

С уважением,

Ольга.

Что это? Компенсация за "високосность"? И почему именно на последнее число

октября?

 

Я уперся в С-шную функцию, дальше - пас :(

Sergey I. Rybin wrote:

Что это? Компенсация за "високосность"? И почему именно на последнее число

октября?

 

 

Я уперся в С-шную функцию, дальше - пас :(

 

Таким образом, можно смело оформлять bug-report с точным указанием:

- версии компилятора;

- версии ядра операционной системы;

- версии библиотеки glibc;

- глобальной установки сдвига локального времени;

- переменных окружения, ответственных за сдвиг локального времени.

 

И ввязать ACT в борьбу с локализацией...

 

 

-- Vadim Godunko

Olga Dolbilina wrote:

 

Доброе время суток!

Поздравляю всех мужчин - участников конференции с Днем защитника Отечества!

 

Спасибо ;-)

 

-- Задаем дату 31.10.2004.

Date := Ada.Calendar.Time_Of (2004, 10, 31, 0.0);

 

-- Прибавляем сутки, ожидая получить 01.11.2004

Date := Date + Ada.Calendar.Day_Duration'Last;

 

-- Получаем день, месяц.

Day := Ada.Calendar.Day (Date);

Month := Ada.Calendar.Month (Date);

...

Получается опять 31.10.2004.

 

Впрочем, если

Date := Date + (Day_Duration'Last + 3601.0);

 

Оля, если бы ты писала тексты тестовых программок чисто на Ада,

примерно вот так.

 

----------------------

with Ada.Calendar;

with Ada.Text_IO;

 

procedure NTime is

use type Ada.Calendar.Time;

Date : Ada.Calendar.Time;

begin

Date := Ada.Calendar.Time_Of (2004, 10, 31, 0.0);

 

Date := Date + Ada.Calendar.Day_Duration'Last;

 

Ada.Text_IO.Put_Line

(Integer'Image (Ada.Calendar.Year (Date))

& Integer'Image (Ada.Calendar.Month (Date))

& Integer'Image (Ada.Calendar.Day (Date)));

end NTime;

------------------------

 

То окружающим было бы несколько легче проверить это на своих конфигурациях.

 

Да действительно я пронаблюдал ту же самую ошибку

на Linux libc 2.2.6 GNAT 5.01a

 

А вот на Windows 2000 GNAT 3.15p и GNAT 5.01a

все отработало как надо.

 

Vadim Godunko wrote:

Таким образом, можно смело оформлять bug-report с точным указанием:

- версии компилятора;

- версии ядра операционной системы;

- версии библиотеки glibc;

- глобальной установки сдвига локального времени;

- переменных окружения, ответственных за сдвиг локального времени.

 

И ввязать ACT в борьбу с локализацией...

 

 

Или можно написать тот же тест чисто на C

и послать это дело в GCC.

Именно так и надлежит поступать!

 

Vadim Godunko wrote:

 

 

Оля, если бы ты писала тексты тестовых программок чисто на Ада,

примерно вот так.

 

----------------------

with Ada.Calendar;

with Ada.Text_IO;

 

procedure NTime is

use type Ada.Calendar.Time;

Date : Ada.Calendar.Time;

begin

Date := Ada.Calendar.Time_Of (2004, 10, 31, 0.0);

 

Date := Date + Ada.Calendar.Day_Duration'Last;

 

Ada.Text_IO.Put_Line

(Integer'Image (Ada.Calendar.Year (Date))

& Integer'Image (Ada.Calendar.Month (Date))

& Integer'Image (Ada.Calendar.Day (Date)));

end NTime;

------------------------

 

То окружающим было бы несколько легче проверить это на своих конфигурациях.

 

 

постараюсь исправиться. :-).

Вот тако пример у меня получился:

 

with Ada.Calendar; use Ada.Calendar;

with Ada.Text_IO; use Ada.Text_IO;

 

procedure Test is

Date : Time;

begin

for Year_Aux in Year_Number'Range loop

for Month_Aux in Month_Number'Range loop for Day_Aux in Day_Number'Range loop

begin Date := Time_Of (Year_Aux, Month_Aux, Day_Aux, 0.0);

Date := Date + Day_Duration'Last;

-- при добавлении целых суток кол-во секунд должно остаться неизменным, т.е. = 0.0

if Seconds (Date) > 0.001 then

Put_Line (Day_Number'Image (Day (Date)) & "/" &

Month_Number'Image (Month (Date)) & "/" &

Year_Number'Image (Year (Date)));

Put_Line ("Seconds = " & Day_Duration'Image (Seconds (Date)));

end if;

exception

when Time_Error | Constraint_Error => null;

end; end loop;

end loop;

end loop;

end Test;

 

В результате получается целый список дат.

Похоже, это закономерность. :-).

 

 

Да действительно я пронаблюдал ту же самую ошибку

на Linux libc 2.2.6 GNAT 5.01a

 

А вот на Windows 2000 GNAT 3.15p и GNAT 5.01a

все отработало как надо.

 

Vadim Godunko wrote:

Таким образом, можно смело оформлять bug-report с точным указанием:

- версии компилятора;

 

gnat 3.15р (20020523)

 

- версии ядра операционной системы;

 

Slackware Linux 2.4.18

 

- версии библиотеки glibc;

 

2.2.5

 

- глобальной установки сдвига локального времени;

- переменных окружения, ответственных за сдвиг локального времени.

 

Где посмотреть?

В Срд, 25.02.2004, в 09:42, Dmitriy Anisimkov пишет:

Да действительно я пронаблюдал ту же самую ошибку

на Linux libc 2.2.6 GNAT 5.01a

tm_sec The number of seconds after the minute, normally in the range 0 to 59,

but can be up to 61 to allow for leap seconds.

Это кусочек мана про сишные функции связанные со временем. Так что вероятно все работает так как и было задумано :)

Serg Kozhemyakin пишет:

 

В Срд, 25.02.2004, в 09:42, Dmitriy Anisimkov пишет:

 

Да действительно я пронаблюдал ту же самую ошибку

на Linux libc 2.2.6 GNAT 5.01a

 

tm_sec The number of seconds after the minute, normally in the range 0 to 59, but can be up to 61 to allow for leap seconds.

 

Это кусочек мана про сишные функции связанные со временем. Так что

вероятно все работает так как и было задумано :)

 

 

 

Т.е. за сутки может "набежать" 3600 секунд разницы между двумя соседними сутками? Или 82_800 в некоторых годах? М-да.

Olga Dolbilina wrote:

end Test;

 

В результате получается целый список дат.

Похоже, это закономерность. :-).

 

Эта закономерность сильно похожа на сдвиги на час вперед/назад весной и осенью.

В Срд, 25.02.2004, в 11:50, Olga Dolbilina пишет:

>tm_sec The number of seconds after the minute, normally in the range 0 to 59,

> but can be up to 61 to allow for leap seconds.

>

>Это кусочек мана про сишные функции связанные со временем. Так что >вероятно все работает так как и было задумано :)

Т.е. за сутки может "набежать" 3600 секунд разницы между двумя соседними сутками? Или 82_800 в некоторых годах? М-да.

Получается что иногда минута может быть до 62 секунд :) ну и

соответственно длинна суток перестает быть константой :(

Serg Kozhemyakin wrote:

В Срд, 25.02.2004, в 11:50, Olga Dolbilina пишет:

 

 

tm_sec The number of seconds after the minute, normally in the range 0 to 59, but can be up to 61 to allow for leap seconds.

 

Это кусочек мана про сишные функции связанные со временем. Так что

вероятно все работает так как и было задумано :)

 

 

Т.е. за сутки может "набежать" 3600 секунд разницы между двумя соседними сутками? Или 82_800 в некоторых годах? М-да.

 

Получается что иногда минута может быть до 62 секунд :) ну и

соответственно длинна суток перестает быть константой :(

Не путать божий дар с яичницей!

 

leap-second (а это и есть 61-я секунда) предназначена исключительно для "выравнивания времени". Используется в двух случаях:

- в обычном календаре за каждые 126 лет набегают одни сутки (поэтому в начале прошлого века и пришлось корректировать время сразу где-то на две недели). В настоящее время раз в N лет производят коррекцию на одну секунду для устранения проблемы;

- в вычислительной техники из-за разброса счета времени на разных машинах при синхронизации используется не прямой перевод часов, а "выравнивание", т.е. вычитание/прибавление одной секунды в конце каждой минуты.

 

Надеюсь понятно, откуда может взяться 62-я секунда. :-)

 

-- Vadim Godunko

В Срд, 25.02.2004, в 18:50, Vadim Godunko пишет:

Получается что иногда минута может быть до 62 секунд :) ну и

соответственно длинна суток перестает быть константой :(

Не путать божий дар с яичницей!

[...]

Надеюсь понятно, откуда может взяться 62-я секунда. :-)

Ну и где сказанное мною противоречит сказанному тобою? или ты хочеш сказать что из-за того что в минуте было 61 секунда длительность дня в секундах не изменилась? ;) А поскольку гнат использует сишные библиотеки то и все вычисления идут в секундах, и к сожаление он, похоже, не учитывает такие события :( Возможно что я глубоко ошибаюсь и все учтено, но тогда странно как-то оно учтено :)

Dmitriy Anisimkov пишет:

 

Olga Dolbilina wrote:

end Test;

 

В результате получается целый список дат.

Похоже, это закономерность. :-).

 

Эта закономерность сильно похожа на сдвиги на час вперед/назад весной и осенью.

Действительно, очень похожа :-). . Тогда получается, что всё правильно? Так и должно быть?

Olga Dolbilina wrote:

Действительно, очень похожа :-). . Тогда получается, что всё правильно? Так и должно быть?

 

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

И в NT такого не наблюдается.

 

Думаю время в Ада не должно сдвигаться на час вперед/назад при арифметических операциях.

В Чтв, 26.02.2004, в 12:54, Dmitriy Anisimkov пишет:

Думаю время в Ада не должно сдвигаться на час вперед/назад при арифметических операциях.

ну тогда получается что все время необходимо считать только по гринвичу и переходить на местное только в случае крайней необходимости :)

Dmitriy Anisimkov пишет:

 

Serg Kozhemyakin wrote:

Думаю время в Ада не должно сдвигаться на час вперед/назад при арифметических операциях.

ну тогда получается что все время необходимо считать только по гринвичу

и переходить на местное только в случае крайней необходимости :)

 

Попрошу не передергивать.

 

Результат арифметической операции, это одно,

а местное время, это совсем другая функциональность.

 

 

Т.е. в Линухе такая коолизия со временем у меня происходит из-за локальных настроек времени (Гринвич +3 (Москва)) ? А где я могу увидеть эти настройки?

Serg Kozhemyakin wrote:

Думаю время в Ада не должно сдвигаться на час вперед/назад при арифметических операциях.

 

 

ну тогда получается что все время необходимо считать только по гринвичу

и переходить на местное только в случае крайней необходимости :)

 

Попрошу не передергивать.

 

Результат арифметической операции, это одно,

а местное время, это совсем другая функциональность.

Olga Dolbilina wrote:

Т.е. в Линухе такая коолизия со временем у меня происходит из-за локальных настроек времени (Гринвич +3 (Москва)) ? А где я могу увидеть эти настройки?

 

Думаю надо искать не сдвиг локального времени относительно гринвича,

а что то типа Automatically adjust clock for daylight saving changes.

 

Я что-то поискал-поискал не нашел.

В Чтв, 26.02.2004, в 13:52, Olga Dolbilina пишет:

Т.е. в Линухе такая коолизия со временем у меня происходит из-за локальных настроек времени (Гринвич +3 (Москва)) ? А где я могу увидеть эти настройки?

В /etc/timezone, /etc/localtime

В Чтв, 26.02.2004, в 13:53, Dmitriy Anisimkov пишет:

Попрошу не передергивать.

Результат арифметической операции, это одно,

а местное время, это совсем другая функциональность.

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

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

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

предсказуемы :) А при вводе/выводе использую тот часовой пояс, который клиент задал. Пока слава богу всех устраивало. :)

Dmitriy Anisimkov wrote:

Serg Kozhemyakin wrote:

 

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

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

предсказуемы :) А при вводе/выводе использую тот часовой пояс, который

клиент задал. Пока слава богу всех устраивало. :)

 

 

А гривичь сдвигается на час весной и осенью ?

 

Нет. Официальное название этого времени Universal Coordinated Time. И именно по нему работают фактически все крупные системы управления.

 

 

-- Vadim Godunko

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти