Defect #12750

Start date set to '2013-01-05 00:00:00' instead of '2013-01-05' when editing an issue

Added by fcx code over 9 years ago. Updated almost 8 years ago.

Status:ConfirmedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues planning
Target version:-
Resolution: Affected version:

Bildschirmfoto 2013-01-08 um 19.39.44.png (15.5 KB) Hans Raaf, 2013-01-08 19:41

Associated revisions

Revision 11138
Added by Jean-Philippe Lang over 9 years ago

Workaround for #12750.

History

#1 Updated by fcx code over 9 years ago

Start Date value gets set to '2013-01-05 00:00:00' instead of '2013-01-05' after clicking update on an existing issue causes validate errors when submitting.

#2 Updated by Jean-Philippe Lang over 9 years ago

  • Resolution set to Cant reproduce

Please read SubmittingBugs.

#3 Updated by Hans Raaf over 9 years ago

I have the same problem.

If you edit an issue it lists "start" and "end" date as "<date> 00:00:00" (it has 00:00:00 behind the date in the field). That seems to be "normal". But since my last update to the newest version it gives and validation error for this fields when I try to save the changes for the ticket.

I am running on german locale (may have to do with it not being reproducible?)

I find the following diffs in issue.rb which "may" be the reason for the problem (I don't speak ruby.. hehe)

diff --git a/app/models/issue.rb b/app/models/issue.rb
index 9a4b93b..2d9228b 100644
--- a/app/models/issue.rb
+++ b/app/models/issue.rb
@@ -67,9 +67,7 @@ class Issue < ActiveRecord::Base

   validates_length_of :subject, :maximum => 255
   validates_inclusion_of :done_ratio, :in => 0..100
-  validates :estimated_hours, :numericality => {:greater_than_or_equal_to => 0, :allow_nil => true, :message => :invalid}
-  validates :start_date, :date => true
-  validates :due_date, :date => true
+  validates_numericality_of :estimated_hours, :allow_nil => true
   validate :validate_issue, :validate_required_fields

   scope :visible, lambda {|*args|
@@ -85,10 +83,6 @@ class Issue < ActiveRecord::Base
   scope :on_active_project, lambda {
     includes(:status, :project, :tracker).where("#{Project.table_name}.status = ?", Project::STATUS_ACTIVE)
   }
-  scope :fixed_version, lambda {|versions|
-    ids = [versions].flatten.compact.map {|v| v.is_a?(Version) ? v.id : v}
-    ids.any? ? where(:fixed_version_id => ids) : where('1=0')
-  }

   before_create :default_assign
   before_save :close_duplicates, :update_done_ratio_from_issue_status, :force_updated_on_change
@@ -538,6 +532,14 @@ class Issue < ActiveRecord::Base
   end

   def validate_issue
+    if due_date.nil? && @attributes['due_date'].present?
+      errors.add :due_date, :not_a_date
+    end
+
+    if start_date.nil? && @attributes['start_date'].present?
+      errors.add :start_date, :not_a_date
+    end
+
     if due_date && start_date && due_date < start_date
       errors.add :due_date, :greater_than_start_date
     end

#4 Updated by Hans Raaf over 9 years ago

I validated that the change to "issue.rb" in changeset #12736 is causing the defect for my system.

But I actually believe that the problem may be that the fields when edited are output with that extra "00:00:00" part behind the date. A fresh date set with the datepicker does not add this "00:00:00".

#5 Updated by Daniel Felix over 9 years ago

  • Category set to Issues planning
  • Status changed from New to Confirmed
  • Resolution deleted (Cant reproduce)

I can confirm this bug too. It also appears in the current trunk (r11137).

I tested this in Firefox with Ruby 1.8.x, Rails 3.2.10, no Plugins enabled.

This bugs seems to be some kind of aftereffect of the datevalidation which is integrated in the latest commits.

#6 Updated by Jean-Philippe Lang over 9 years ago

Works for me. Which database are you using?

#7 Updated by Hans Raaf over 9 years ago

MySQL 5.1.66

Do you have the output as in the screen I attached when you edit an issue?

I have it now.. but with the old validation code everything is working.

With the new validation code I get the validation errors (not a date).

I believe the '00:00:00' are not wanted by you anyway and now introduce the problem.

#8 Updated by Jean-Philippe Lang over 9 years ago

No, I don't have the trailing 00:00:00 when editing an issue.

I have it now.. but with the old validation code everything is working.

The new validation consider this invalid indeed (unlike the previous one), I understand that, but did you have the offending 00:00:00 before r11124? I need to know why you get this and not me.

#9 Updated by Jean-Philippe Lang over 9 years ago

  • Subject changed from Start Date valuegets sets value to '2013-01-05 00:00:00' instead of '2013-01-05' after clicking update on an existing issue causes validate errors when submitting. to Start date set to '2013-01-05 00:00:00' instead of '2013-01-05' when editing an issue

#10 Updated by Hans Raaf over 9 years ago

Yes I have it pre 11124. My current branch is at trunk@11086 and I believe it was some months ago already like that!

Maybe that helps?

  • actionmailer (3.2.9)
  • actionpack (3.2.9)
  • activemodel (3.2.9)
  • activerecord (3.2.9)
  • activeresource (3.2.9)
  • activesupport (3.2.9)
  • arel (3.0.2)
  • builder (3.0.0)
  • bundler (1.2.1)
  • coderay (1.0.8)
  • erubis (2.7.0)
  • fastercsv (1.5.5)
  • hike (1.2.1)
  • i18n (0.6.1)
  • journey (1.0.4)
  • jquery-rails (2.0.3)
  • json (1.7.6)
  • mail (2.4.4)
  • metaclass (0.0.1)
  • mime-types (1.19)
  • mocha (0.12.3)
  • multi_json (1.5.0)
  • mysql (2.8.1)
  • net-ldap (0.3.1)
  • pg (0.14.1)
  • polyglot (0.3.3)
  • rack (1.4.2)
  • rack-cache (1.2)
  • rack-openid (1.3.1)
  • rack-ssl (1.3.2)
  • rack-test (0.6.2)
  • rails (3.2.9)
  • railties (3.2.9)
  • rake (10.0.3)
  • rdoc (3.12)
  • rmagick (2.13.1)
  • ruby-openid (2.1.8)
  • shoulda (2.11.3)
  • sprockets (2.2.2)
  • sqlite3 (1.3.6)
  • thor (0.16.0)
  • tilt (1.3.3)
  • treetop (1.4.12)
  • tzinfo (0.3.35)
  • yard (0.8.3)

#11 Updated by Daniel Felix over 9 years ago

Hi there,

I just found this:
http://stackoverflow.com/questions/7290575/invalid-date-format-specification-in-gemspec

Maybe this relates to this? Seems to be the same error. Maybe this is our problem.
But, is there some way to force a valid format?

#12 Updated by Hans Raaf over 9 years ago

Well I think 00:00:00.000000000Z is something else than 00:00:00 and looks to me like something different.

#13 Updated by Jean-Philippe Lang over 9 years ago

Daniel Felix wrote:

Hi there,

I just found this:
http://stackoverflow.com/questions/7290575/invalid-date-format-specification-in-gemspec

No, it's not related.

I'm able to reproduce with ruby1.8.7 and the mysql gem. I don't know when it was introduced. It was working fine when I was using 1.8.7 (long time ago :-).

#14 Updated by Jean-Philippe Lang over 9 years ago

Issue#start_date_before_type_cast returns a Mysql::Time with ruby + mysql, that's insane.
I've committed a workaround in r11138 so that validation does not fail.

#15 Updated by Daniel Felix over 9 years ago

Thank you! I will try the fresh revision tomorrow morning!

#16 Updated by Daniel Felix over 9 years ago

Hi,

I just tried r11138 but it doesn't seem to fix the problem. I still get the validation errors.

#17 Updated by Olivier Houdas almost 9 years ago

I had the same issue, not fixed with r11138 patch.
I changed the regex you used to
unless before_type_cast =~ /\A\d{4}-\d{2}-\d{2}( \d{2}:\d{2}:\d{2})?( \+\d{4})?\z/ && value
and now it works.
I'm using CentOS, Ruby 2.0.0, MS SQL Server, and the dates I'm getting are of the following formats:
2013-09-12 02:00:00 +0200

#18 Updated by Michel Behr almost 8 years ago

I'm using m.redmine.org for testing, and the date format does not include time and timezone - shouldn't it be working...?

Also available in: Atom PDF