Comments below.
--- smcphelan <[EMAIL PROTECTED]> wrote:
> XLFDT expects a valid date input. So no it cannot
> convert a number from 1-12 to a month.
I am not following you. Why would allowing the date
digits in a FM date to displayed as the text name of
month indicate an invalid date?
Sample code:
w "Last visit was ",$$DTFormat(LastVisit,"mmmm,
yyyy."),!
Last visit was October, 1989.
>I am not sure what you mean about not displaying year
only.
I didn't say *not* displaying year only. I said that
FMTE^XLFDT can't display year only. Your example
below requires that the month/day/second digits be
void. Thus it can not take an arbitrary FMDate and
display the year only. You have to blow away
information in an arbitrary date by somehow masking
digits (see below).
> Here are some simple examples of what it can do that
addresses most of your comments:
I don't feel that you have addressed "most" of the
issues that I enumerated. As I re-list them below, I
see that only one of the issues is addressed.
1. convert month 08 into August or Aug.
2. Access partial information... i.e. year only, month
only, day only, hour only, seconds only.
3. Include user text.
(I agree that you show that below *can* be done for a
12 hr clock)
4. Show time in any format other than "@XX:XX". ("@"
is not widely used in displaying times outside VistA.)
5. Display time BEFORE the date
6. Any arbitrary order of displaying each data
element, intermixed with any arbitrary punctation.
Comments below.
>
> W $$FMTE^XLFDT(3000000)
> 2000
>
You had to artificially zero out the digits for
month,day etc to achieve this. You couldn't do this
for any arbitrary date with out extra steps. I.e.:
SET SOMEDATE=1790231.123255
W $$FMTE^XLFDT(SOMEDATE)
S SOMEDATE=SOMEDATE\1 ;blow away time part
S $EXTRACT(SOMEDATE,4,7)="0000" ;blow away month,day
part
W $$FMTE^XLFDT(SOMEDATE)
-->
Feb 31, [EMAIL PROTECTED]:32:55
1979
> W $$FMTE^XLFDT($$NOW^XLFDT,"5PZ")
> 05/17/2005 2:19:25 pm
Can you get rid of the @ sign without using the 12 hr
clock (am/pm) format?, i.e.
05/17/2005 23:19:25
>
> W $$FMTE^XLFDT($$NOW^XLFDT,"P")
> May 17, 2005 2:19:39 pm
>
> W $$FMTE^XLFDT(3050805)
> Aug 05, 2005
You had to alter your date to alter your output (i.e.
remove the decimal portion of your date. I don't
think XLFDT can restrict the display of time-portion
without altering the value of one's FMDate, i.e.
W $$FMTE^XLFDT(SOMEDATE\1)
>
> W $$DOW^XLFDT(DT)
> Tuesday
This is a nice function. I agree that this is a good
function. I think I will call this function to get
the days of the week in my formater.
>
> W $$DOW^XLFDT(DT,1)
> 2
>
For the issues below, I think we have a
misunderstanding. I never claimed to be providing a
full date/time package. Just an improvement to the
*text formating* function (FMTE^XLFDT). Thus for the
functions you outline below, I would use the other API
calls in the XLFDT package.
> Does you utility allow for the conversion of the
> ANSI standard M date,time,
> $H?
>
> Does your utility allow for the conversion of FM
> date.time to HL7 date.time
> and vice versa?
>
> Does you utility allow for the conversion of $H to
> HL7 date.time?
>
> Does your utility allow for the adding (or
> subtracting) of either days,
> hours, minutes, or seconds to a FM (or $H) date.time
> and return a valid FM
> (or $H) date.time?
>
> Does you utility allow for the conversion of
> date.time to a numeric number
> that can be used in mathematical calculations?
>
> Does your utility allow for time zones and as such
> for UCT?
>
> Does your utility account for all leap years over
> 1000 year time frame?
>
> If you can answer Yes to all of these questions,
> then your utility
> approaches the robustness of XLFDT.
>
> I question the usefulness of "at exactly" in a date
> when dealing with
> physicians. When was the last time any patient had
> their scheduled
> appointment kept by the practice "at exactly" the
> scheduled date and time?
I agree that the words "at exactly" would never be
used in my office. I used that example because it is
immediately obvious that it is a user defined string.
But what would be more likely to be used would be
other punctuation, as follows:
4:32 pm; January 27,1945 (added ';')
[05/14/2005] (enclosed in brackets) etc.
Jan. 27,1945; 4:32.40 pm (use . as seconds separator)
My point was not to denegrate the XLFDT package. Just
to provide an extension for myself for one function.
If anyone else is interested in the extra flexibility
fine. Otherwise by all means stick with the existing
FMTE^XLFDT. This isn't some kind of contest.
:-)
Kevin
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
