Skip to content
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.

DateTime.now not capturing time component #16

Open
amiracam opened this issue Jan 29, 2014 · 7 comments
Open

DateTime.now not capturing time component #16

amiracam opened this issue Jan 29, 2014 · 7 comments

Comments

@amiracam
Copy link

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
Copy link
Author

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
Copy link
Owner

Can you post a gist with an example?

@amiracam
Copy link
Author

Yes
On Jan 29, 2014 10:52 AM, "Adrian Madrid" [email protected] 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
Copy link
Author

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
Copy link
Owner

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: [email protected]

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
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
Copy link
Author

np, thanks

On Wednesday, January 29, 2014, Adrian Madrid [email protected]
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: [email protected]

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
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
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants