Open amiracam opened 10 years ago
amiracam
commented
10 years ago 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
commented
10 years ago Can you post a gist with an example?
amiracam
commented
10 years ago 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/aemadrid/orientdb-jruby/issues/16#issuecomment-33597000 .
amiracam
commented
10 years ago 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
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
commented
10 years ago 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
commented
10 years ago 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.
Charles A. Monteiro www.monteirosfusion.com sent from the road
amiracam
commented
10 years ago 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
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.