Ahhh, the joys of reinventing the wheel.
I'll check out XLFDT. I thought I had searched for
such a function before and only found that 2-3
pre-package formats were available. Oh well.
Kevin
--- smcphelan [EMAIL PROTECTED] wrote:
It is nice you have developed a M API to convert
dates.
Thurman:
Thank you. Can you tell us a little about yourself, and how you got into VistA. If it fits with our story, do you mind if we quote you by name?
Steve
Thurman Pedigo [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/16/2005 11:21 AM
Please respond to hardhats-members
To:
GCN article, "House committee likely to cut HealtheVet
funds", see:
http://appserv.gcn.com/vol1_no1/daily-updates/35816-1.html
Should you feel the urge to become an
activist:
The House committee:
www.va.gov/OCA/chart_hmqlvara.htm
The Senate committee:
OK, I have had a chance to look at the FMTE^XLFDT
function, and I don't think it is fair to say that
that function can do what mine can. Here is the
documentation from the Kernal API:
---
$$FMTE^XLFDT(x[,y])
Input Parameters x:
(required) VA FileMan date. y:
See XLFDT it is more robust than what you show here.
I didn't notice that you say XLFDT is MORE robust than
what I showed. Can you give an example that you feel
my function would not be able to do?
Kevin
--- smcphelan [EMAIL PROTECTED] wrote:
It is nice you have developed a M API to
XLFDT expects a valid date input. So no it cannot convert a number from
1-12 to a month. I am not sure what you mean about not displaying year
only. Here are some simple examples of what it can do that addresses most
of your comments:
W $$FMTE^XLFDT(300)
2000
W
This actually seems like useful functionality to me. Of course, I would
advocate using XLFDT where possible, and would only store dates in
internal format, but better date formatting capabilities (not to
mention the ability to parse formatted dates) would be a good thing.
Something like Java's
I agree with all of the following, that FileMan functions generally need
to be evaluated in a FileMan context. George Timson recently (in the last
year or so) has provided an enhancement to FileMan's Single Data Retriever
that may have a bearing on this discussion. The field argument (the 3rd
Greg,
Thanks.
The function can be cut and pasted from the wikki:
http://openforum.worldvista.org/~forum/index.php?title=DTFormat_--_an_extension_to_%24%24FMTE%5EXLFDT
I agree that XLFDT is a good package.
Kevin
--- Greg Woodhouse [EMAIL PROTECTED]
wrote:
This actually seems like useful
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
Most of this list has heard more than
enough of me. Will be glad to respond offline, or phone, if that is acceptable
tx/t
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, May 17, 2005 7:17
AM
To:
W $$FMTE^XLFDT(300)
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
Hey, guys, there will always be room for new ways of doing things. The
Kernel tools are there and heavily used. But as Kevin found, it didn't
quite work the way he needed. Kevin has fulfilled his need with the tool he
has constructed. There are numerous ways of providing services that are
13 matches
Mail list logo
