Parse::Date should support Times and Dates not just DateTimes

[ericcj]

serialization should probably just give you DateTimes and coerce any of these instead of handing out Parse::Dates in the first place, but at the very least we shouldn't blow up on Times and Dates, or even ActiveSupport::TimeWithZone

[ericcj]

we should do away with Parse::Date entirely and just serialize Times, Dates, and DateTimes properly on requests

[adelevie]

Agreed.

Sent from my iPhone

On Jan 21, 2013, at 8:16 AM, Eric Jensen notifications@github.com wrote:

we should do away with Parse::Date entirely and just serialize Times, Dates, and DateTimes properly on requests

—
Reply to this email directly or view it on GitHub.

[adelevie]

So proposed api should just be:

game_score["set_at"] = DateTime.now
# or
game_score["set_at"] = Time.now
# or
game_score["set_at"] = Date.now
# or
game_score["set_at"] = "01-22-2013" # mm-dd-yyy 

Also, I think we should still keep Parse::Date in master for a while until people have sufficient time to change. Maybe throw a warning?

Also also, should the serialization occur on request or right when the attribute gets set? Does it make any difference?

[ericcj]

I don't think we should mess with parsing people's strings into dates for
them, but directly taking DateTime and Time would be nice. Don't forget
ActiveSupport::TimeWithZone which behaves like Time but does not
inherit any of them (active support does monkeypatch all three to respond to acts_like_time? though). The only real requirement is that the thing passed in
can be serialized with #iso8601(3), which all of these can as long as you
explicitly require 'time' and require 'date'.

Other nice properties would be that you can compare it directly ala
a['setAt'] < b['setAt'] and to external times like Time.now - a['setAt'].
A way of achieving both of these things would be to check if
respond_to?(:to_time) && !is_a(String) (since active_support adds
String#to_time) and if so then use that to normalize them all to Time
instances in that setter. the stdlib defines to_time but not to_datetime
so switching to Time makes sense. probably leave Parse::Date in but log
its deprecation with Kernel#warn to discourage its use.

While we're in that setter, it's a little weird that we allow you to set
values as any class that implements to_json (which is often any object
since active_support defines Object#to_json). At the very least we should
convert Parse::Objects you set directly to pointers instead of defaulting
to calling to_json on them which stores them as a hash in the parse table.

On Tue, Jan 22, 2013 at 11:52 AM, Alan deLevie notifications@github.comwrote:

So proposed api should just be:

game_score["set_at"] = DateTime.now# orgame_score["set_at"] = Time.now# orgame_score ["set_at"] = "01-22-2013" # mm-dd-yyy

Also, I think we should still keep Parse::Date in master for a while
until people have sufficient time to change. Maybe throw a warning?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-12553724.

[ericcj]

are you sure you want to close this? it's insanely annoying that you have to put DateTimes into parse-ruby-client and it barfs on Times

[xavdid]

Whoops! Thought this was a different one.

[rhymes]

@ericcj let's discuss about this, I have some experiencing dealing with Date / Time / Timezone and so on with Rails and I agree. All parse-ruby-clients should do is:

• take the object
• convert it to UTC if it's not
• call #iso8601(3) on it

How do you propose we go about this?