DateTime conversion issues when doing unit test

[eminarcissus]

The code are as following Looks like the last digit 05.41213Z and 05.412130Z are not the same when doing ecto conversion(they are compared as String when returned from the view layer

Don't know if this is a bug or is something I'm missing here Any help would be appreciated :)

code: json_response(conn, 200) == render_json(ActivityView, "show.json", activity: gate)
     lhs:  %{"data" => %{"activity_holder" => "ActivityHolder8", "background_img" => nil, "description" => "ActivityDescription8", "end_datetime" => nil, "id" => 54, "is_deleted" => false, "is_stopped" => false, "name" => "Activity8", "wechat_link" => nil, "start_datetime" => "2017-01-13T19:20:05.41213Z"}}
     rhs:  %{"data" => %{"activity_holder" => "ActivityHolder8", "background_img" => nil, "description" => "ActivityDescription8", "end_datetime" => nil, "id" => 54, "is_deleted" => false, "is_stopped" => false, "name" => "Activity8", "wechat_link" => nil, "start_datetime" => "2017-01-13T19:20:05.412130Z"}}
     stacktrace:
       test/controllers/activity_controller_test.exs:46: (test)

[bitwalker]

This should be fixed in recent versions of TImex - there was a padding issue with microseconds, could you give it a shot and let me know?

[eminarcissus]

Tested it once again, looks like still a no go here.

 Assertion with == failed
 code:  json_response(result, 200) == render_json(ActivityView, "show.json", activity: gate)
 left:  %{"data" => %{"activity_holder" => "ActivityHolder43", "description" => "ActivityDescription43", "end_datetime" => nil, "id" => 994, "image_id" => nil, "is_deleted" => false, "is_stopped" => false, "name" => "Activity43", "link" => "", "start_datetime" => "2017-02-12T09:55:15.1868Z"}}
 right: %{"data" => %{"activity_holder" => "ActivityHolder43", "description" => "ActivityDescription43", "end_datetime" => nil, "id" => 994, "image_id" => nil, "is_deleted" => false, "is_stopped" => false, "name" => "Activity43", "link" => "", "start_datetime" => "2017-02-12T09:55:15.186800Z"}}

[eminarcissus]

timex version version "3.1.11" timex_ecto version "3.1.1"

[bitwalker]

Could you show me the source DateTime struct? If the precision of microseconds is 6 coming from Ecto/the database, then this is not a bug - however if the precision is being overriden by timex_ecto, then there is a bug.

[bitwalker]

Seeing the actual database field value will be the most helpful it looks like

[eminarcissus]

schema "activities" do field :name, :string,default: "" field :activity_holder, :string,default: "" field :description, :string,default: "" field :start_datetime, Timex.Ecto.DateTime,usec: true field :end_datetime, Timex.Ecto.DateTime,usec: true field :is_stopped, :boolean, default: false field :is_deleted, :boolean, default: false timestamps() end

This is my schema

And this is my web/web.ex file which have Timestamps defined with use Timex.Ecto.Timestamps,usec: true

[bitwalker]

Could you provide the field value from the database? In order for me to isolate whether this is a bug or not, I have to troubleshoot with that value.

[eminarcissus]

select start_datetime,end_datetime,inserted_at,updated_at from activities; start_datetime | end_datetime | inserted_at | updated_at ---------------------+--------------+----------------------------+---------------------------- 2017-02-01 15:44:06 | | 2017-02-17 15:44:30.139765 | 2017-02-17 15:44:30.139772

[bitwalker]

It looks like those values don't match the original values you opened the issue with - but with the ones you've provided, it looks like the microsecond precision is 6 in the database, hence the zero-padding when converted by Ecto/Timex. This isn't a bug, since we must preserve the precision we are given, and not reduce precision just because there are trailing zeroes.

[eminarcissus]

Thx for the head up. Yeps, issues are created with unit test erros, I cannot reproduce this bug,it just happens sometimes. So if I run 10 times mix test it can have different times of == assertive errors which make it really hard to look into. I will see if there are any other methods to do the test, thx very much for the help :)

[bitwalker]

No problem :). If you do reproduce it, try to capture the database value and reopen the issue with it, and I'll take a closer look!