DateTime.now not capturing time component

[amiracam]

In attempting to persist a new instance of a Class which has an attribute defined to type DateTime, if in the constructor i.e. Document.create ... , I pass in DateTime.now

the persisted record shows the correct date but the time component is set to midnight , if I instead pass this: DateTime.now.proxy_object, then both the date and time component show up correctly in the db.

[amiracam]

actually I'm wrong, eyes deceiving this late at night, when I pass in DateTime.now.proxy_object, the time component is correct but the date is incorrect i.e. specifically the year component is off , instead of 2014 it consistently shows up as 3914

[aemadrid]

Can you post a gist with an example?

[amiracam]

Yes
On Jan 29, 2014 10:52 AM, "Adrian Madrid" notifications@github.com wrote:

Can you post a gist with an example?

Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-33597000
.

[amiracam]

Adrian:

somethings to note:

the schema is created via the studio tool, and there IS a defined schema. The attributes in question are defined as DATETIME. If defined as STRING btw, the correct string representation of the time component shows up.

I have hacked a unit test (incomplete) but it demonstrates the issue.

Here's the gist

1. TestCase: https://gist.github.com/amiracam/8693124
2. output: https://gist.github.com/amiracam/8693144

Interestingly , the returned object from the "create" method seems to show a properly constructed DateTime which includes a proper Time component , however , if you were to check with the Studio tool, the documents show the time component to be midnight. Also note that if one actually does a query and inspects the returned record for those DATETIME specified attributes i.e. "submitted" and "notified" that those show up with an incorrect time component i.e. set to midnight.

thanks for looking into this and thanks for having created this useful wrapper for OrientDB

[aemadrid]

thanks for taking the time to investigate. I’m in the middle of a launch for this weekend so I’m not sure how much time and when I’m going to be able to employ. I will let you know when I’m done working on it though.

Sincerely,

Adrian Madrid | TimeWorxs
m: 801.815.1870 | e: aemadrid@gmail.com

On January 29, 2014 at 10:57:57 AM, amiracam (notifications@github.com) wrote:

Adrian:

somethings to note:

the schema is created via the studio tool, and there IS a defined schema. The attributes in question are defined as DATETIME. If defined as STRING btw, the correct string representation of the time component shows up.

I have hacked a unit test (incomplete) but it demonstrates the issue.

Here's the gist

TestCase: https://gist.github.com/amiracam/8693124
output: https://gist.github.com/amiracam/8693144
Interestingly , the returned object from the "create" method seems to show a properly constructed DateTime which includes a proper Time component , however , if you were to check with the Studio tool, the documents show the time component to be midnight. Also note that if one actually does a query and inspects the returned record for those DATETIME specified attributes i.e. "submitted" and "notified" that those show up with an incorrect time component i.e. set to midnight.

thanks for looking into this and thanks for having created this useful wrapper for OrientDB

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

[amiracam]

np, thanks

On Wednesday, January 29, 2014, Adrian Madrid notifications@github.com
wrote:

thanks for taking the time to investigate. I'm in the middle of a launch
for this weekend so I'm not sure how much time and when I'm going to be
able to employ. I will let you know when I'm done working on it though.

Sincerely,

Adrian Madrid | TimeWorxs
m: 801.815.1870 | e: aemadrid@gmail.com

On January 29, 2014 at 10:57:57 AM, amiracam (notifications@github.com)
wrote:

Adrian:

somethings to note:

the schema is created via the studio tool, and there IS a defined schema.
The attributes in question are defined as DATETIME. If defined as STRING
btw, the correct string representation of the time component shows up.

I have hacked a unit test (incomplete) but it demonstrates the issue.

Here's the gist

TestCase: https://gist.github.com/amiracam/8693124
output: https://gist.github.com/amiracam/8693144
Interestingly , the returned object from the "create" method seems to
show a properly constructed DateTime which includes a proper Time component
, however , if you were to check with the Studio tool, the documents show
the time component to be midnight. Also note that if one actually does a
query and inspects the returned record for those DATETIME specified
attributes i.e. "submitted" and "notified" that those show up with an
incorrect time component i.e. set to midnight.

thanks for looking into this and thanks for having created this useful
wrapper for OrientDB

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.<
https://ci3.googleusercontent.com/proxy/d9Z8-43xaJijztFnjNIhqYs5RhI9CDLnnFTYV4zMXM0ejbe4qM6_vjY5RURPVyhqCqWnP2_UEzyod5CGjtEQB_w4lGiRo3sB-chX8PuV1l3zDpGEG_qpNNb5KqHBf1Y2sXmdxZfJBszAIIVwq1Ogrw2j0RxgxFGVvULMcjhtZvMknDeoBQSeNTQsQLDD2zLNVr-jy-rnsRsMSKmWtUyaVmPkbvK44pyb_6ZrdXpurqwGk5pnaqNuUabpEj1HvKPDaRdORNGngPhK_YMpJh5JL0xeUO0D=s0-d-e1-ft#https://github.com/notifications/beacon/508408__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNjU1MTg3MCwiZGF0YSI6eyJpZCI6MjQ0NzcxNDJ9fQ==--b2b18e8b72c76b4012bab9c27b5778faad76a4cf.gif

Charles A. Monteiro
www.monteirosfusion.com
sent from the road

[amiracam]

update

just got time myself to work with this again. I don't have a solution to the problem but I do seem to have a workaround to my immediate problem. Specifically, if I set in the OrientDB studio a field to be DateTime but in Ruby use Time i.e. as in setting to Time.now, then I do get the full timestamp representation i.e. including a date component e.g. Thu Feb 13 21:43:46 EST 2014, the object that I get back though is not a Ruby object but a Java::JavaUtil::Date. So recap, from Ruby DateTime will not work but Time will and specifically DateTime will only capture the date component and set the time to midnight whereas when using Time.now , will represent both date and time components correctly.

-Charles