Hi, Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html But a date 1966-2-17 is persisted as a DateAndtime of value 1966-02-16T23:00:00+00:00 in the repository, which when retrieve will then be 1996-16-2, and so on.... Exactly the utc time for a local 1966-17-2T00:00:00+00:00 Could it be the implicated code? : (GratuitousIncompatibilities intToDateAndTime: (GratuitousIncompatibilities dateToMilliseconds: '1966-2-17' asDate)) asDate => 16 Février 1966 And even worst: (GratuitousIncompatibilities intToDate: (GratuitousIncompatibilities dateToMilliseconds: '1966-2-17' asDate)) asDate => 15 Février 1966 Hilaire -- Dr. Geo http://drgeo.eu
Concerning this problem, one option I found is to get far away of the Voyage/Mongo Date/DateAndTime representation/conversion and stick to string, not really efficience, but well... mongoBirthday <mongoDescription> ^ VOToOneDescription new attributeName: 'birthday'; accessor: (MAPluggableAccessor read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] write: [:person :string |string ifNotNil: [person birthday: string asDate]]); yourself Le 03/03/2017 à 21:12, Hilaire a écrit :
Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
-- Dr. Geo http://drgeo.eu
Hi Hilaire, it is interesting to see your posts and having similar topics as me when starting to use voyage. I ended up with saving ZTimestamps. But I will think about storing strings too, because this is more readable when having direct look into mongo. There was a discussion in slack a few days ago (February, 21st) about saving Dates in voyage. Regards Sabine 2017-03-04 11:21 GMT+01:00 HilaireFernandes [via Smalltalk] < ml-node+s1294792n4937262h17@n4.nabble.com>:
Concerning this problem, one option I found is to get far away of the Voyage/Mongo Date/DateAndTime representation/conversion and stick to string, not really efficience, but well...
mongoBirthday <mongoDescription> ^ VOToOneDescription new attributeName: 'birthday'; accessor: (MAPluggableAccessor read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] write: [:person :string |string ifNotNil: [person birthday: string asDate]]); yourself
Le 03/03/2017 à 21:12, Hilaire a écrit :
Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
-- Dr. Geo http://drgeo.eu
------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Voyage-and-Date-tp4937235p4937262.html To start a new topic under Pharo Smalltalk Users, email ml-node+s1294792n1310670h65@n4.nabble.com To unsubscribe from Pharo Smalltalk Users, click here <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&nod...> . NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>
-- View this message in context: http://forum.world.st/Voyage-and-Date-tp4937235p4937269.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I think sticking to a date string is the safest thing to do. Especially if you use iso yyyy-mm-dd because the database indexes are predix based and are able to sort and build ranges. So you don't loose much. The problem is regarding the conceptually incompatible offset and #asDate. #asDate just cuts off minutes hours and seconds from am DateAndTime. So if the offset has a startDate of yesterday asDate will give a date yesterday. In my code I either use "asLocal asDate" or date as string. No better solution so far
Am 04.03.2017 um 12:15 schrieb Sabine Manaa <manaa.sabine@gmail.com>:
Hi Hilaire,
it is interesting to see your posts and having similar topics as me when starting to use voyage. I ended up with saving ZTimestamps. But I will think about storing strings too, because this is more readable when having direct look into mongo. There was a discussion in slack a few days ago (February, 21st) about saving Dates in voyage.
Regards Sabine
2017-03-04 11:21 GMT+01:00 HilaireFernandes [via Smalltalk] <[hidden email]>:
Concerning this problem, one option I found is to get far away of the Voyage/Mongo Date/DateAndTime representation/conversion and stick to string, not really efficience, but well...
mongoBirthday <mongoDescription> ^ VOToOneDescription new attributeName: 'birthday'; accessor: (MAPluggableAccessor read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] write: [:person :string |string ifNotNil: [person birthday: string asDate]]); yourself
Le 03/03/2017 à 21:12, Hilaire a écrit :
Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
-- Dr. Geo http://drgeo.eu
If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Voyage-and-Date-tp4937235p4937262.html To start a new topic under Pharo Smalltalk Users, email [hidden email] To unsubscribe from Pharo Smalltalk Users, click here. NAML
View this message in context: Re: Voyage and Date Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I would love to have a digest of the problems you encountered and the solution. Because like that we could write a better documentation. I cannot because I do not face the problems (since I'm not developing real apps for lack of time/concentration....). Stef On Sat, 04 Mar 2017 12:15:39 +0100, Sabine Manaa <manaa.sabine@gmail.com> wrote:
Hi Hilaire,
it is interesting to see your posts and having similar topics as me when starting to use voyage. I ended up with saving ZTimestamps. But I will think about storing strings too, because this is more readable when having direct look into mongo. There was a discussion in slack a few days ago (February, 21st) about saving Dates in voyage.
RegardsSabine
2017-03-04 11:21 GMT+01:00 HilaireFernandes [via Smalltalk] <[hidden email]>:
Concerning this problem, one option I found is to get far away of the Voyage/Mongo Date/DateAndTime representation/conversion and stick to string, not really efficience, but well... mongoBirthday<mongoDescription>^ VOToOneDescription new attributeName: 'birthday'; accessor: (MAPluggableAccessor read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] write: [:person :string |string ifNotNil: [person birthday: stringasDate]]); yourself
Le 03/03/2017 à 21:12, Hilaire a écrit :
Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
--Dr. Geohttp://drgeo.eu
If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Voyage-and-Date-tp4937235p4937262.htmlTo start a new topic under Pharo Smalltalk Users, email [hidden email]To unsubscribe from Pharo Smalltalk Users, click here. NAML
View this message in context: Re: Voyage and Date Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Using Opera's mail client: http://www.opera.com/mail/
Hi Stephan, I am maintaining such a digest, with links to the discussion on the list. I will post it once I am done with Voyage. Hilaire Le 04/03/2017 à 21:34, stepharong a écrit :
I would love to have a digest of the problems you encountered and the solution. Because like that we could write a better documentation.
I cannot because I do not face the problems (since I'm not developing real apps for lack of time/concentration....).
-- Dr. Geo http://drgeo.eu
On Sun, 05 Mar 2017 09:49:02 +0100, Hilaire <hilaire@drgeo.eu> wrote:
Hi Stephan,
I am maintaining such a digest, with links to the discussion on the list. I will post it once I am done with Voyage.
super cooooooooooooooooooooooooooooooooooooooooooooooooool
Hilaire
Le 04/03/2017 à 21:34, stepharong a écrit :
I would love to have a digest of the problems you encountered and the solution. Because like that we could write a better documentation.
I cannot because I do not face the problems (since I'm not developing real apps for lack of time/concentration....).
-- Using Opera's mail client: http://www.opera.com/mail/
yes, this is a good solution. the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). So if you want a Date, you need to do some conversion. Esteban
On 4 Mar 2017, at 11:25, Hilaire <hilaire@drgeo.eu> wrote:
Concerning this problem, one option I found is to get far away of the Voyage/Mongo Date/DateAndTime representation/conversion and stick to string, not really efficience, but well...
mongoBirthday <mongoDescription> ^ VOToOneDescription new attributeName: 'birthday'; accessor: (MAPluggableAccessor read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] write: [:person :string |string ifNotNil: [person birthday: string asDate]]); yourself
Le 03/03/2017 à 21:12, Hilaire a écrit :
Not sure it is related to this: http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
-- Dr. Geo http://drgeo.eu
Hi Esteban, This is a recurring problem. May be Voyage should come with the necessary adaptor to have the Date right. It is likely *every* Voyage user faces the problem, and it does not fell good about the framework to have issue on such elementary feature. Hilaire Le 05/03/2017 à 10:06, Esteban Lorenzano a écrit :
the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). So if you want a Date, you need to do some conversion.
-- Dr. Geo http://drgeo.eu
Voyage cannot guess user intentions. But yes we could add a helper to do the transformation easier (like a special description for dates), but you will always need to configure that by hand. Esteban
On 5 Mar 2017, at 10:22, Hilaire <hilaire@drgeo.eu> wrote:
Hi Esteban,
This is a recurring problem. May be Voyage should come with the necessary adaptor to have the Date right. It is likely *every* Voyage user faces the problem, and it does not fell good about the framework to have issue on such elementary feature.
Hilaire
Le 05/03/2017 à 10:06, Esteban Lorenzano a écrit :
the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). So if you want a Date, you need to do some conversion.
-- Dr. Geo http://drgeo.eu
participants (5)
-
Esteban Lorenzano -
Hilaire -
Norbert Hartl -
Sabine Manaa -
stepharong