Date change from mm/dd/yyyy to dd/mm/yyyy format

[Ajay]

What is the effort involved in changing the date format in WorldVistA
from mm/dd/yyyy to dd/mm/yyyy? Is anyone using VistA in this date
format?

[David Carter]

I ran into this problem with reports and I have a macro to converts dates in excel if you need it.  I don't know if all the VistA flavors have the same format though.  I haven't tried them all, but I am guessing that the current format is standard.    

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[David Whitten]

The easy stuff is changing the NUMDATE function (or better, adding another one) in the FUNCTION File #0.5 and changing the %DT and XLFDT routines.

The hard stuff is recognizing the use of $EXTRACT() and the concatenate code that makes this format effectively forming this date format "on the fly".

David

PS: by the way, changing this kind of code throughout VistA shows the need for us to work on a common code base that we all share. It definitely complicates the code as it changes the code throughout the system, and like internationalization, in general, makes it harder to maintain with a standard source (from the VA) that won't have those changes made.

[r...@rcresearch.us]

Currently there is a common format for time/date that VistA uses,
yyymmdd.hhmmss is how it is stored internally. The problem is one of the
output transforms used and the coordination of the various applications to
use the proper output transform. To David W's point, we could put such a
node in the ^%ZOSV global that any complying application could call.

>>> Hardhats+u...@googlegroups.com<Hardhats%2Bunsu...@googlegroups.com>

>>>
>>
>> --
>> http://groups.google.com/group/Hardhats
>> To unsubscribe, send email to

>> Hardhats+u...@googlegroups.com<Hardhats%2Bunsu...@googlegroups.com>

[George Timson]

For FileMan, I have already done the date-internationalization work--
in fact I standardized the date output over 10 years ago. Please read
what I have written under "INTERNATIONALIZATION" in the "read.me"
document at http://www.hardhats.org/fileman/MSC.html.

--George Timson

[Sam Habiel]

I have built on George's work to make the system spit out the proper
format and read the proper format when using the two existant APIs in
roll and scroll VISTA for data display. But, as David W mentions,
there are lots of places which don't use the API's and instead do a
$Extract on the date.

CPRS and other clients are a whole another story. The Danes already
adapted CPRS to deal with Danish dates, and they have shared the
source code. Find it on opensourcevista.net.

Furthermore, I need to point out that many countries use YYYY/MM/DD
instead of DD/MM/YYYY.

Sam

[JohnLeo Zimmer]

Pending full support for internalization,
YYYY/MM/DD may have an advantage as a default format that will not cause confusion if it has to be mixed with either DD/MM/YY or MM/DD/YY.

And YYYY/DD/MM is unlikely to be <anyone's> standard.  :-)

jl.z

[Jari Friis Jørgensen]

Hello Ajay

Just a short note. In Denmark we have VistA running at clinic where we
have changed the dateformat to dd/mm/yyyy.
The way we did this was to leave as much as the VistA code alone and
then basically added extra functions in the client.
Lars the developer on this can tell you much more about that...To put
it short we have a VistA version that supports Danish langauge
, dateformat dd/mm/yyyy as well as a visitation module where patients
are on the patient list with a number and then removed from
the list when a doctor signs for a the current visitation note. The
version also includes lookup for CPR-service (Danish Social Security
Number)
and some other stuff as well as some integrations in regard to lab
tests.

Our version is build on Kevins VistA version and we will soon look
into seeing how to get our updates into the newest version, since we
need
some of the functions from the new versions in regard to scanning
pictures.

Jari

[K.S. Bhaskar]

yyyy-mm-dd & yyyymmdd are ISO 8601 standard and can be freely used
anywhere in the world. The standard also specifies standards for
representing time (see http://en.wikipedia.org/wiki/ISO_8601).

Regards
-- Bhaskar

GT.M - Rock solid. Lightning fast. Secure. No compromises.

On 09/05/2010 02:27 PM, JohnLeo Zimmer wrote:
> Pending full support for internalization,
> YYYY/MM/DD may have an advantage as a default format that will not cause
> confusion if it has to be mixed with either DD/MM/YY or MM/DD/YY.
>
> And YYYY/DD/MM is unlikely to be <anyone's> standard. :-)
>
> jl.z

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________