http://bugs.mysql.com/bug.php?id=22695
Как воспроизвести такой баг в ява проге и протестить его через junit
Есть идеи?
Здравствуйте, Аноним, Вы писали:
> http://bugs.mysql.com/bug.php?id=22695
> Как воспроизвести такой баг в ява проге и протестить его через junit
> Есть идеи?
Я не совсем понял что значит из java. Если именно парсинг данных, то вот примерно так:
final SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm");
simpleDateFormat.setTimeZone(TimeZone.getTimeZone("Canada/Eastern"));
simpleDateFormat.setLenient(false);
final Date date = simpleDateFormat.parse("2012-03-11 02:49:54");
Оно кидает исключение ParseException: Unparseable date
Как обернуть это в JUnit думаю сам догадаешься.
Я использовал другую дату, мне точно известную, потому что не понял какая там в баге таймзона используется.
Если тебе нужно протестить именно mysql, то это уже integration test, какой-нибудь сервер mysql поднимать и слать запросы через jdbc.
Здравствуйте, Аноним, Вы писали:
А>http://bugs.mysql.com/bug.php?id=22695
А>Как воспроизвести такой баг в ява проге и протестить его через junit
А>Есть идеи?
Главная идея состоит в том, что хранить в базе локальное время без указания часового пояса — это уже баг.
Здравствуйте, ., Вы писали:
.>Здравствуйте, Аноним, Вы писали:
>> http://bugs.mysql.com/bug.php?id=22695
>> Как воспроизвести такой баг в ява проге и протестить его через junit
>> Есть идеи?
.>Я не совсем понял что значит из java. Если именно парсинг данных, то вот примерно так:
.>.> final SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm");
.> simpleDateFormat.setTimeZone(TimeZone.getTimeZone("Canada/Eastern"));
.> simpleDateFormat.setLenient(false);
.> final Date date = simpleDateFormat.parse("2012-03-11 02:49:54");
.>
.>Оно кидает исключение ParseException: Unparseable date
.>Как обернуть это в JUnit думаю сам догадаешься.
.>Я использовал другую дату, мне точно известную, потому что не понял какая там в баге таймзона используется.
.>Если тебе нужно протестить именно mysql, то это уже integration test, какой-нибудь сервер mysql поднимать и слать запросы через jdbc.
Мне и самому не все тут ясно.
Примерно так. При попытке вставить дату или может быть timestamp в некоторых случаях mySql валится в исключение.
Я поразеваю, что всем виной неверная дата или неверная дата для mySql в какой-то временной зоне.
Типа у меня все работает, а кое-где кое у кого возникает редкий глюк.
Сначала хочу воспроизвести глюк тестом.
из доков на mySql
//A timestamp. The range is '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07'
//UTC. TIMESTAMP values are stored as the number of seconds since the epoch ('1970-01-01 00:00:00' UTC).
//A TIMESTAMP cannot represent the value '1970-01-01 00:00:00' because that is equivalent to 0 seconds from
//the epoch and the value 0 is reserved for representing '0000-00-00 00:00:00', the “zero” TIMESTAMP value.
Date date = new java.util.Date(1251136551293L); по-моему в некоторых временных зонах дата уйдет в 1969 год и вставка в MySql
должна выпадсть в экспешн. Наверно есть и други невкусные даты. Может быть в разных субд могут быть другие невалидные даты.
Нужен список таких дат. Составлять вручную?
Хочу каким-то тестом отловить все методы где есть вставка дат в базу данных и подсунуть им некорекные даты.
Может быть и нужно поднимать MySql и т.д. но хотелось бы обойтись без этого.
Пока ищу идеи, как это правильно делать.
Может бы есть способ как то проверять дату перед вставкой на валидность?
Вот такие пироги.
Здравствуйте, Аноним, Вы писали:
А>Мне и самому не все тут ясно.
А>Примерно так. При попытке вставить дату или может быть timestamp в некоторых случаях mySql валится в исключение.
А>Я поразеваю, что всем виной неверная дата или неверная дата для mySql в какой-то временной зоне.
А>Типа у меня все работает, а кое-где кое у кого возникает редкий глюк.
А>Сначала хочу воспроизвести глюк тестом.
А>из доков на mySql
А>//A timestamp. The range is '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07'
А>//UTC. TIMESTAMP values are stored as the number of seconds since the epoch ('1970-01-01 00:00:00' UTC).
А>//A TIMESTAMP cannot represent the value '1970-01-01 00:00:00' because that is equivalent to 0 seconds from
А>//the epoch and the value 0 is reserved for representing '0000-00-00 00:00:00', the “zero” TIMESTAMP value.
А>Date date = new java.util.Date(1251136551293L); по-моему в некоторых временных зонах дата уйдет в 1969 год и вставка в MySql
Ну это похоже больше на микросекунды, а не миллисекунды. Проверь тут —
http://www.onlineconversion.com/unix_time.htm — выводит 41616 год. Ясен пень в 2038 не влазит.
А>должна выпадсть в экспешн. Наверно есть и други невкусные даты. Может быть в разных субд могут быть другие невалидные даты.
А>Нужен список таких дат. Составлять вручную?
Если у тебя даны миллисекунды с начала эпохи, то дата по определению валидная.
А>Хочу каким-то тестом отловить все методы где есть вставка дат в базу данных и подсунуть им некорекные даты.
А>Может быть и нужно поднимать MySql и т.д. но хотелось бы обойтись без этого.
А>Пока ищу идеи, как это правильно делать.
Надо начать с того, чтобы в точности понять что такое unix time, что такое таймзона и что такое валидная дата и что у тебя там творится в системе — где какой формат и что он значит.
А>Может бы есть способ как то проверять дату перед вставкой на валидность?
Зависит от.
Здравствуйте, ., Вы писали:
А>>Date date = new java.util.Date(1251136551293L); по-моему в некоторых временных зонах дата уйдет в 1969 год и вставка в MySql
.>Ну это похоже больше на микросекунды, а не миллисекунды. Проверь тут — http://www.onlineconversion.com/unix_time.htm — выводит 41616 год. Ясен пень в 2038 не влазит.
Нет, это миллисекунды. Классический unixtime — секунды от начала эпохи — это (в окрестностях нашего времени) десятизначное число (из которых первые пять — скорее дата, вторые — скорее время). Дата в примере — 1251.1 365:51.293 — это 2009-08-24T17:55:51.293Z.
