-
Notifications
You must be signed in to change notification settings - Fork 21
DateTime.now not capturing time component #16
Comments
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 |
Can you post a gist with an example? |
Yes
|
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 |
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 On January 29, 2014 at 10:57:57 AM, amiracam ([email protected]) 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 thanks for looking into this and thanks for having created this useful wrapper for OrientDB — |
np, thanks On Wednesday, January 29, 2014, Adrian Madrid [email protected]
Charles A. Monteiro |
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.
The text was updated successfully, but these errors were encountered: