UTCDATEONLY should probably only serialize to date about quickfixn HOT 10 CLOSED

We have a DateOnly field, but DDField is still wrong.

from quickfixn.

DateOnly and TimeOnly are in DateTimeField.cs

from quickfixn.

Do we have example of failure? (Something I can build a test around?)

from quickfixn.

No Fixtest that covers this yet.
Just need to make a test expecting that fields that are UTCDateOnly and
UTCTimeOnly. I'll work on that test, and let you know when its done.

On Wed, Nov 30, 2011 at 9:37 AM, gbirchmeier <
[email protected]

wrote:

Do we have example of failure? (Something I can build a test around?)

---

Reply to this email directly or view it on GitHub:
#5 (comment)

Kirk

from quickfixn.

Ok, this bug isn't about Message decoding from string (which this doesn't appear to affect), it's about the basic class interface.

There's 2 parts to this:

1. The Ruby code generator generates time-only and date-only fields as DateTimeFields. We should fix this.
2. The DD created in the engine is not using the correct DateTime-derived types when validating messages. That's what the DDField.cs function will affect.

Note to Kirk: After creating a message from a string, you have to call dd.Validate(). That's where the DD comes into play and wrong-type exceptions get thrown. Should have realized it sooner.

from quickfixn.

The validate function! Been so long.
We're you able to get this in? I can hop on it of not.

Kirk

On Nov 30, 2011, at 5:16 PM, [email protected] wrote:

Ok, this bug isn't about Message decoding from string (which this doesn't appear to affect), it's about the basic class interface.

There's 2 parts to this:

1. The Ruby code generator generates time-only and date-only fields as DateTimeFields. We should fix this.
2. The DD created in the engine is not using the correct DateTime-derived types when validating messages. That's what the DDField.cs function will affect.

Note to Kirk: After creating a message from a string, you have to call dd.Validate(). That's where the DD comes into play and wrong-type exceptions get thrown. Should have realized it sooner.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

from quickfixn.

I was not. I might take it up on the plane ride back, though. Or
Monday morning. If you want to hit it, I don't mind. Let me know if
you do though.

from quickfixn.

Will do. I'll see what I get to today.

Kirk

On Dec 2, 2011, at 7:36 AM, [email protected] wrote:

I was not. I might take it up on the plane ride back, though. Or
Monday morning. If you want to hit it, I don't mind. Let me know if
you do though.

On Wed, Nov 30, 2011 at 6:40 PM, kkozel
[email protected]
wrote:

The validate function! Been so long.
We're you able to get this in? I can hop on it of not.

Kirk

On Nov 30, 2011, at 5:16 PM, [email protected] wrote:

Ok, this bug isn't about Message decoding from string (which this doesn't appear to affect), it's about the basic class interface.

There's 2 parts to this:

1. The Ruby code generator generates time-only and date-only fields as DateTimeFields. We should fix this.
2. The DD created in the engine is not using the correct DateTime-derived types when validating messages. That's what the DDField.cs function will affect.

Note to Kirk: After creating a message from a string, you have to call dd.Validate(). That's where the DD comes into play and wrong-type exceptions get thrown. Should have realized it sooner.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

---

Reply to this email directly or view it on GitHub:
#5 (comment)

---

Reply to this email directly or view it on GitHub:
#5 (comment)

from quickfixn.

I started working on this yesterday.

from quickfixn.

Turns out we're not validating the types of any fields within repeating groups.

I found this because DateOnly/TimeOnly only occurs in repeating groups in our DDs. My tests weren't working because of this.

So I'll be fixing that too.

from quickfixn.