загадочные даты 01.01.1970 и 19.01.2038
#1
Отправлено 22 ноября 2012 - 09:57
возникала ошибка с датами 01.01.1970 и 19.01.2038 ?
в моем случае, у объявления есть период его публикации
так вот "по непонятным" мне причинами у некоторых объявлений дата начала/конца меняется на эти загадочные даты 01.01.1970 и 19.01.2038
воспроизвести не могу ее
#2
Отправлено 22 ноября 2012 - 10:51
Unix время: с 01.01.1970 - начинается отсчет.в 19.01.2038 (03:14:08) значение переменной для времени привысит 2^31.
что может привести к ошибке.
Это довольно-таки стандартные даты для проверки программ работающих со временем.
Почему возникают эти данные? Смотреть надо в код или с программистами, где используется даты, как и на что они завязаны в программе.
#5
Отправлено 25 ноября 2012 - 21:59
#6
Отправлено 26 ноября 2012 - 12:45
Думаю, что не целесообразно тратить много времени на отчаяные попытки воспроизвести баг. Баг можно и так создать, программисту будет быстрее найти причину.
#7
Отправлено 29 ноября 2012 - 20:41
Если бага не идет к Тестеру, то вот как Тестеру идти к баге:есть какие-нибудь предположения для воспроизведения ошибки ?
1) Внимательно изучите по требованиям, какой рабочий диапозон дат ожидается, (чтобы не создавать надуманных трудностей);
2) Попросите девелоперов включить подробное логгирование (запись в файл истории событий ввода/вывода данных, т.е. какие соответствующие даты пользователь задавал, как они обрабатывались/сохранялись, как подготавливались для отображения), и можете ждать, когда проблема проявится - по логу будет проще найти её причину.
3) Если у вас есть соответствующие знания,- проверьте (белый ящик):
3.1) корректность валидаторов вводимых значений дат (с учётом локали и [min;max]);
3.2) наличие глюко-функциональности по автозамене невалидной даты (по формату или диапозону значений д м г) на некую валидную;
4) Если есть возможность - автоматизируйте сценарий ввода/вывода даты, подготовьте тестовые наборы: позитивные (хоть перебором - лишних тестов в случае, когда нет идей, есть только глюки - не бывает) и негативные - этих побольше/разных
Вопрос: karakoz, можете представить ваши тестовые наборы (классы эквивалентности):
- что не сработало для воспроизведения?
- что планируете?
#8
Отправлено 04 декабря 2012 - 05:43
взяли след ошибки, есть проблема со статусами объявлениями...
#9
Отправлено 04 декабря 2012 - 14:43
Сейчас наткнулся на ошибку SQL Server'a c датами меньше, чем 1753/01/01. С этой датой работает, а 1752/12/31 и меньше уже отваливается.
Может кто знает в чем там дело?
#10
Отправлено 04 декабря 2012 - 15:46
Небольшой оффтопик.
Сейчас наткнулся на ошибку SQL Server'a c датами меньше, чем 1753/01/01. С этой датой работает, а 1752/12/31 и меньше уже отваливается.
Может кто знает в чем там дело?
говорят: "Тестирование скучная, монотонная работ" :)
ограничение типа datetime
1 января 1753 года — 31 декабря 9999 года
ИМХО почему:
Т.к. до 1752 года Англия и её колонии не принимали григорианского календаря для синхронизации календаря с лунным циклом (Calendar (New Style) выкинули 10 дней: 9/3/1752 - 9/13/1752.
Т.е. год получился "укороченным", что повод ограничить тип переменной, дабы не разбираться с внезапными граблями на программном уровне, куда делись 10 дней. Как месяцы друг в друга перегонять и т.п.
Ещё интересные даты:
10/5/1582 - 10/14/1582 - эти даты были исключены из григорианского календаря папской буллой о переходе от юлианского к григорианскому календарю. Т.е. как-раз, переход на "новый стиль", если угодно. Следующим днём после 4 октября стало 15 октября.
Т.е. логическая граница, для требований\ПО... а то мало-ли, решит кто архивы старые хранить.
И да, разработчики тоже историю могут знать... :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных