Talk:Date Data Type
From CometWiki
(Difference between revisions)
| Line 1: | Line 1: | ||
Posted by Grant Foraker on September 14, 2009 at 14:43:13: | Posted by Grant Foraker on September 14, 2009 at 14:43:13: | ||
| - | Adding a Date data type to Comet has been discussed at several past Dealer/Developer meetings. So, as a baby step, can we add a "D" field type to #CFILES. | + | Adding a Date data type to Comet has been discussed at several past Dealer/Developer meetings. So, as a baby step, can we add a "D" field type to #CFILES. |
| - | + | . | |
| - | Right now the majority of dates in my files are either "YYYYMMDD" or "MM/DD/YYYY". The "YYYYMMDD" ones for date sorting (in keys mostly) and the "MM/DD/YYYY" ones for display. The Date Serial Number is another possible option. | + | Right now the majority of dates in my files are either "YYYYMMDD" or "MM/DD/YYYY". The "YYYYMMDD" ones for date sorting (in keys mostly) and the "MM/DD/YYYY" ones for display. |
| - | + | The Date Serial Number is another possible option. | |
| - | So, in the Reporter | + | . |
| - | + | So, in the Reporter | |
| - | SELECTING IF TRANS.DATE EQ "%FromDate%" | + | . |
| - | + | SELECTING IF TRANS.DATE EQ "%FromDate%" | |
| - | would prompt a Date Picker because TRANS.DATE was a "D" instead of a "S" field. | + | . |
| + | would prompt a Date Picker because TRANS.DATE was a "D" instead of a "S" field. | ||
:Posted by Jon Sacks on September 15, 2009 at 06:28:44: | :Posted by Jon Sacks on September 15, 2009 at 06:28:44: | ||
In Reply to: Date data type posted by Grant Foraker on September 14, 2009 at 14:43:13: | In Reply to: Date data type posted by Grant Foraker on September 14, 2009 at 14:43:13: | ||
| - | + | . | |
All dates should be stored in the system as serial date/time and the mask applied indicates the way it should be displayed. | All dates should be stored in the system as serial date/time and the mask applied indicates the way it should be displayed. | ||
| Line 20: | Line 21: | ||
In Reply to: Re: Date data type posted by Jon Sacks on September 15, 2009 at 06:28:44: | In Reply to: Re: Date data type posted by Jon Sacks on September 15, 2009 at 06:28:44: | ||
| - | + | . | |
Jon, of course, is right. Dates should be stored as serial date/time. Sadly the Q machine did not know about such sophistication. | Jon, of course, is right. Dates should be stored as serial date/time. Sadly the Q machine did not know about such sophistication. | ||
#CFILES has this legacy thing to deal with. | #CFILES has this legacy thing to deal with. | ||
And, of course, I agree with Grant BUT we need more than a D type. We need type codes like those so mnemonically defined for DATE2NUM. | And, of course, I agree with Grant BUT we need more than a D type. We need type codes like those so mnemonically defined for DATE2NUM. | ||
Easy to remember; flows trippingly from the tongue. Sadly we need more than one date code. | Easy to remember; flows trippingly from the tongue. Sadly we need more than one date code. | ||
Revision as of 11:05, 7 October 2009
Posted by Grant Foraker on September 14, 2009 at 14:43:13:
Adding a Date data type to Comet has been discussed at several past Dealer/Developer meetings. So, as a baby step, can we add a "D" field type to #CFILES. . Right now the majority of dates in my files are either "YYYYMMDD" or "MM/DD/YYYY". The "YYYYMMDD" ones for date sorting (in keys mostly) and the "MM/DD/YYYY" ones for display. The Date Serial Number is another possible option. . So, in the Reporter . SELECTING IF TRANS.DATE EQ "%FromDate%" . would prompt a Date Picker because TRANS.DATE was a "D" instead of a "S" field.
- Posted by Jon Sacks on September 15, 2009 at 06:28:44:
In Reply to: Date data type posted by Grant Foraker on September 14, 2009 at 14:43:13: . All dates should be stored in the system as serial date/time and the mask applied indicates the way it should be displayed.
- Posted by Steve Auerbach on September 15, 2009 at 07:41:34:
In Reply to: Re: Date data type posted by Jon Sacks on September 15, 2009 at 06:28:44: . Jon, of course, is right. Dates should be stored as serial date/time. Sadly the Q machine did not know about such sophistication. #CFILES has this legacy thing to deal with. And, of course, I agree with Grant BUT we need more than a D type. We need type codes like those so mnemonically defined for DATE2NUM. Easy to remember; flows trippingly from the tongue. Sadly we need more than one date code.
