MSC Fileman and European Date Formats...
Sam Habiel
yyyy, e.g. dd/mm/yyyy or dd.mm.yyyy) for both input and output?
The readme says:
-Formatting of date output is now consistently done throughout
all the end-user routines. Changing the global node ^DD("DD") will
change the way all FileMan dates are output. Re-running ^DINIT will not
change this node.
Okay... never mind... it does for output, but I haven't tested it.
Sam Habiel
Sam Habiel
Sam
George Timson
http://www.hardhats.org/fileman/pm/cl_dt1.htm. You could force the
%DT variable to always contain "I". Note:
>SET %DT="AEQI" DO ^%DT
DATE: 3 4 55 (APR 03, 1955)
This is if the user's language is still ENGLISH. If DUZ("LANG") is
greater than 1, then you can see that the %DT routine branches at the
top to execute the MUMPS code stored in this field:
.85,20.2 DATE INPUT 20.2;E1,245 MUMPS
--George
George Timson
supposed to allow input of dates in "International" form, I noticed a
strange restriction. Month names aren't allowed in this mode. E.g.,
"24JAN", which normally is accepted, is rejected in "I" mode.
I'll fix this in the next release of MSC FileMan (1037).
--George Timson
Sam Habiel
I was trying to create a new visit in CPRS, and it wouldn't accept the
date that CPRS was feeding it. So I thought it might be because of
that, and indeed it is. I append the "I" to the %DT variable so that
it would handle dates correctly when in the format the rest of the
world uses.
Here's my language file entry:
ID NUMBER: 10 NAME: ARABIC
DATE INPUT: S %DT=$G(%DT)_"I" D CONT^%DT Q
DATE/TIME FORMAT (FMTE): N %T,%R,%F S %T="."_($E($P(Y,".",2)_"000000",1,7)) S
%F="3" D F3^DILIBF S Y=%R
GTM>S %DT="TSX"
GTM>S X="Jan 28,2010@08:37"
GTM>d ^%DT
GTM>w Y
3100128.0837
GTM>k Y
GTM>w X
Jan 28,2010@08:37
GTM>s %DT="TSXI"
GTM>d ^%DT
GTM>w Y
-1
Sam
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
George Timson
for you.
I commented out the 100th line and slightly changed line 41 and 75.
--George Timson
Sam Habiel
later today.
Sam
Sam Habiel
I had a bug in my language code (it kept adding "I" to %DT).
The new one looks like this:
ID NUMBER: 10 NAME: ARABIC
DATE INPUT: S:$G(%DT)'["I" %DT=$G(%DT)_"I" G CONT^%DT
DATE/TIME FORMAT (FMTE): N %T,%R,%F S %T="."_($E($P(Y,".",2)_"000000",1,7)) S
%F="3" D F3^DILIBF S Y=%R
I can now type in a date in the new visit box in CPRS in either using
the named month or using international dates and it works. Other parts
of CPRS crash though because they are passing dates to Fileman
explicitly in the American Format.
GTM>W %DT
AESXI
GTM>D ^%DT
DATE: JAN 1 2007 (JAN 1,2007)
GTM>D ^%DT
DATE: January 1 2007 (JAN 1,2007)
GTM>D ^%DT
DATE: 3182007 ??
DATE: 31082007 (AUG 31,2007)
GTM>D ^%DT
DATE: 10272009 ??
DATE: 27102009 (OCT 27,2009)
GTM>D ^%DT
DATE: 11 jan 2009 (JAN 11,2009)
GTM>D ^%DT
DATE: 32 jan 2009 ??
DATE: 31/1/09 (JAN 31,2009)
GTM>D ^%DT
DATE:
GTM>D ^%DT
DATE: 2007-01-23 ??
DATE: 2007-01-23 ??
DATE:
Sam
Sam Habiel
https://bugs.launchpad.net/openvista-server/+bug/515123
Trac server giving me trouble... but it has the old fileman anyways...
so what's the point?
Sam
Nancy Anthracite
having. Please just reset your password and it will be back to usual for you.
--
Nancy Anthracite
Sam Habiel
Sam
George Timson
looks like you are implicitly asking for one more enhancement to %DT.
You want it to understand that when a four-digit year comes first, as
in '2007-01-23', then the second number is the month and the third is
the day of the month. Would this be allowed if and only if the "I"
parameter were present? And if the date can be imprecise (%DT doesn't
contain "X") then is '2007-01' legal as in input for "January, 2007".
You see, %DT never expected the year to come first.
--George
On Jan 31, 5:56 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Thank you George. It works...
>...
....
Sam Habiel
can worry about that. I shouldn't have included it in my capture.
Sam
في Jan 31, 2010، الساعة 6:25 PM، كتب George Timson
<gti...@pacbell.net>:
George Timson
See http://hardhats.googlegroups.com/web/DIDT%20%282%29.m?gsc=5tfQMgsAAABN1vBzJjxkDnERWJ6-jEMs
But this will NOT depend on the "I" parameter. And it works only for
precise dates like 2010-01-31.
--George
On Jan 31, 11:33 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Oh don't worry about that. If and when the Swedes adopt Vista, they
> can worry about that. I shouldn't have included it in my capture.
>
> Sam
>
> في Jan 31, 2010، الساعة 6:25 PM، كتب George Timson
> <gtim...@pacbell.net>:
Sam Habiel
I tried the new routine. It works as expected for US dates if I put
the year first; however, in the international setting ("I"), when I
put the year first, I expect it to treat the next two numbers as month
and then day. However, what happens is that "I" makes it treat the
numbers as day then month, so that 2009-3-2 (March 2, 2009) is
interpreted with an "I" flag as February 3, 2009.
In other words, this format should behave the same whether in the US or not.
The other issue is that dates without delimiters in this format don't
work. So 20090302 won't work. I don't know if it's practical to fix
this one.
GTM>S %DT="AESX"
GTM>D ^%DT
DATE: 2010-22-22 ??
DATE: 2010-11-22 (NOV 22, 2010)
GTM>W Y
3101122
GTM>W %DT
AESX
GTM>D ^%DT
DATE: 11/22/2239 (NOV 22, 2239)
GTM>W Y
5391122
GTM>D ^%DT
DATE: 22/11/2239 ??
DATE:
GTM>W %DT
AESX
GTM>S %DT="ASEXI"
GTM>D ^%DT
DATE: 22/11/2239 (NOV 22, 2239)
GTM>W Y
5391122
GTM>D ^%DT
DATE: 2010-22-22 ??
DATE: 2010-22-11 (NOV 22, 2010)
GTM>D ^%DT
DATE: 2010-11-22 ??
DATE:
GTM>S %DT="ASEX"
GTM>D ^%DT
DATE: 2010-3-2 (MAR 02, 2010)
GTM>S %DT="ASEXI"
GTM>D ^%DT
DATE: 2010-3-2 (FEB 03, 2010)
As always... thank you very much for your efforts.
Sam
2010/2/1 George Timson <gti...@pacbell.net>:
Steven McPhelan
--
Steve
"A lie told often enough becomes truth" - Vladimir Lenin
K.S. Bhaskar
This information is available in the operating system's locale (Linux
or Windows). The strftime() function exists on both platforms to convert
the date and time to a string in the format of the locale of the process.
Doing it this way will allow Fileman to operate correctly in all
locations without changes.
The international standard for dates is ISO-8601 which should be used for
any date that should be understood across country boundaries.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 02/05/2010 08:49 AM, Steven McPhelan wrote:
> What is the international standard for date formats when the format has
> a specific pattern? It seems your requirement that yyyy first must be
> in the yyyy-mm-dd format rather than yyyy-dd-mm. However, we know that
> the US uses mmm dd, yyyy format while may countries use dd mmm, yyyy format.
>
> 2010/2/4 Sam Habiel <sam.h...@gmail.com <mailto:sam.h...@gmail.com>>
>
> Sorry for taking long to get back.
>
> I tried the new routine. It works as expected for US dates if I put
> the year first; however, in the international setting ("I"), when I
> put the year first, I expect it to treat the next two numbers as month
> and then day. However, what happens is that "I" makes it treat the
> numbers as day then month, so that 2009-3-2 (March 2, 2009) is
> interpreted with an "I" flag as February 3, 2009.
[KSB] <...snip...>
_____________
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.
_____________
K.S. Bhaskar
readable.
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 02/05/2010 12:25 PM, K.S. Bhaskar wrote:
> IMHO, Fileman should not be making decisions about date and time
> formats. This information is available in the operating system's locale
> (Linux or Windows). The strftime() function exists on both platforms to
> convert the date and time to a string in the format of the locale of the
> process. Doing it this way will allow Fileman to operate correctly in
> all locations without changes.
>
> The international standard for dates is ISO-8601 which should be used
> for any date that should be understood across country boundaries.
>
> Regards
> -- Bhaskar
>
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
r...@rcresearch.us
control the display of date time formats. A single machine in one
location may be supporting hospitals in a number of different time zones.
The display of the date and time should reflect the view point of the
user. So there is a real issue if the data center is in Denver is
handling hopitals on the West Coast. There is a consult being given from
a hospital in Birmingham, Alabama through the same CPU in the one
location. All of the actors here have a point of view of time.
How is this to be tracked? VistA users are asociated with a location.
Eventually, once Internationalization gets configured, each of these
different users may also choose their preferred language acceptence.
That will mean that each user may have their favored representation of
date/time/currency/units of measure. Date can also reflect the calendar
used as well. In the Heijri calendar, it is a Lunar calendar which
depends upon the geographic location as to the application of leap-days.
So location and mapping to the Gregorian Calendar will be a bit diceie.
I would love to see how the Linux OS handles the Heijri conversions.
Best wishes; Chris
K.S. Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 02/05/2010 01:45 PM, r...@rcresearch.us wrote:
> Actually, Bhaskar, there are some very valid reasons for letting VistA
> control the display of date time formats. A single machine in one
> location may be supporting hospitals in a number of different time zones.
> The display of the date and time should reflect the view point of the
> user.
[KSB] Agreed.
> So there is a real issue if the data center is in Denver is
> handling hopitals on the West Coast. There is a consult being given from
> a hospital in Birmingham, Alabama through the same CPU in the one
> location. All of the actors here have a point of view of time.
[KSB] Quite independent of electronic health records, one hopes of course
that all the consultants can agree on when the patient was medicated.
> How is this to be tracked? VistA users are asociated with a location.
> Eventually, once Internationalization gets configured, each of these
> different users may also choose their preferred language acceptence.
> That will mean that each user may have their favored representation of
> date/time/currency/units of measure. Date can also reflect the calendar
> used as well. In the Heijri calendar, it is a Lunar calendar which
> depends upon the geographic location as to the application of leap-days.
> So location and mapping to the Gregorian Calendar will be a bit diceie.
> I would love to see how the Linux OS handles the Heijri conversions.
[KSB] The system clock keeps time in UTC. Although there is a system
timezone, each process can have its own time zone. So it really doesn't
matter where the user is and where the system is, as long as they are all
on Planet Earth.
Linux (and UNIX) systems have handled this for many, many, years and
Windows also handles time this way since, I believe Windows Vista.
I don't have other languages or locales installed on my system, so I
can't give you an example from an Islamic or Thai calendar. However,
should you know any Mayan doctors, they will I am sure be happy to know
that today is Long count 12.19.17.1.10; tzolkin 7 0c; haab 8 Pax - at
least that's what my Linux laptop tells me.
Regards
-- Bhaskar
George Timson
date and time formats. This information is available in the
operating system's locale (Linux
It would be great if I could use an external call in %DT (and
elsewhere). Just please review the various "%DT" input parameters at
http://www.hardhats.org/fileman/pm/cl_dt1.htm
and tell me whether your utility of choice can replicate all their
functionality (allow time, don't allow time, assume past date, etc.).
Thanks,
--George
George Timson
files?&sort=date) now fixes everything you want. "20100206" should now
work equivalently to "02062010" in American mode or "06022010" in
International mode.
Please contact me offline for further enhancing, if needed. I am sure
the group is tiring of this.
--George Timson
JohnLeo Zimmer
This is cool stuff.
Highest regards,
jl.z
...and we <are> a strange group.
Nancy Anthracite
--
Nancy Anthracite
K.S. Bhaskar
I was hoping to take a detailed look today, but it took me several hours
to clear the snow from the driveway - it was perhaps the deepest I have
had to clear in one go in Malvern. So, I'll look at it next weekend. At
first glance it seems quite doable, but the proof of the pudding is in
the eating, or maybe the proof of the software is in its execution.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
Steven McPhelan
--
Steve
The end of democracy will be when the electorate learns that it vote itself largess from the public coffers - Source Unknown
George Timson
FileMan field for date that will store the full UTC date including
time zone offset..." There are innumerable places in VistA code where
FileMan dates are manipulated as raw global data, and we need to
preserve backwards-compatibility with all that.
--George Timson
glilly
convert from FM date to UTC, which is required by the CCR standard.
Here is a link to the code for $$FMDTOUTC^C0CUTIL
https://trac.opensourcevista.net/browser/ccr/trunk/p/C0CUTIL.m
In order to process incoming CCRs and CCDs we are going to need the
reverse utility to convert from UTC to Fileman date/time. (Any help on
this would be greatly appreciated).
I don't know to what extent these routines would meet all the
requirements for processing UTC dates.
gpl
K.S. Bhaskar
in any records and therefore should not need a new date field. The
computer system operates on UTC, and all times should be stored as UTC.
The only occasion to convert time zones is for input/output purposes,
where the timezone that a user (process) is in can be used to convert for
display, as well as for processing input.
I suppose something similar may occur for interfacing to equipment that
only reports a single time.
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
Steven McPhelan
time is stored in internal FM format with no UTC. Then that database
is moved to another time zone. Of course the server has the correct
timezone for it location. So now 2 pm in FM format that was
originally PT is now 2pm ET but should be 5pm. Have you not altered
the medical record?
Once the date and time has been imbedded into the VistA database you
have lost all reference to the original time zone for which that
record was recorded. In most of these real situations the database
still serves the original timezone so one would just set the server
time clock to that original timezone. However, due to growth and
expansion this same situation has arisen for which you cannot set the
server back to the original time zone.
As I stated we cannot change the original FM date definition. In this
global economy we may have clincians making evaluations on patients
who EMR server is offset by 12 hours from the clinician. There is
clinical data for which it is absolutely critical to know the absolute
date and time of the results and not the relative date and time. If
this is not addressed and if VistA is not totally rewritten, I do not
see how a single VistA database can service patients in multiple
timezones without potentially compromising patient care if absolute
date and times are not recorded.
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
--
r...@rcresearch.us
You haven't necessarily lost the context of the location where the
record has come from if the location and the date of day-light savings
time is part of the Kernel Site Parameters file. But you are right, the
time with the time zone should be stored if the UTC is to generated. As
you know, the perspective of the viewer should be maintained and I have
floated a couple of straw man documents about how to keep the time zone
with the time/date reference. The idea is to provide a couple of
replacement routines for %DT and %DTC that will co-exist with the
original code. As the applications are migrated, the references for %DT
and %DTC can be modified to the more tolerant form of these utilities so
that the old date/time formats can be modified to fit the more explicite
time zone versions. In that the user is associated with a location, the
current time zone is established and can be applied as suggested.
Converting everything to UTC means the loss of information. The ability
to convert a date/time in one location to the view-point of the observer
in another time zone is critical to the success of the new time zone
conversion routines.
Now, here is a little quiz. If the location is not geographically
fixed (on board ship or aircraft), what time zone is used to record
events (drug administrations, etc)? Reply with your answers and I will
tell you what I have heard as the solution.
Steven McPhelan
the time zone of where the server is actually located since most
likely the moving object would up-link to a server versus having the
database on board.
Sam Habiel
I will post in the next couple of days the results of my investigations re: dates in VistA, with a plea to the Danes to show us what they did with CPRS.
Sam
JohnLeo Zimmer
to support the passengers and crew... (Whether the physical server
resides on the ship or somewhere "in the cloud" would be irrelevant.)
Ideally, time would need to be UTC with the "actor's" Longitude
specified for any particular event. The patient may be on board ship
or in the air being evacuated to shore. The physician may be on board
or a consultant looking in from another continent.
Seems to me that time in ViSta is going to be local in all cases. The
challenge may be to start tagging events with their location as well
as that local time. Default location would be the location of the
health facility. But the patient may be in Sam in Jordan, or Peter at
GMT+05:30 somewhere in India, or my sister in the Marshal Islands (18
hours east of me here on the west coast of Iowa).
The server's location should be irrelevant. It's physical location may
be unknown to the users. And with a virtual server residing "in the
cloud it" may not have ANY specifiable physical location.
jl.z
Limping along in CST, getting older in UTC.
And what about an installation on Mars where the "sol" is 24h 39min?
K.S. Bhaskar
various stages of (dis)organization, and your new year's resolution is to
organize your images, you don't start with the closet. That's a recipe
for failure and a repeated new year's resolution. You start with any new
photos you take, and you keep them organized. As time and energy
permits, you attack the closet (or at least, its contents).
So, we should separate past VistA deployments from future VistA
deployments. Future VistA deployments should all run on computer systems
whose clocks run on UTC, and VistA itself should run on UTC. In a global
world where servers, patients and clinicians may all be in different
locations, UTC is after all the Universal Time Coordinate at least for
this planet. VistA should maintain all records in UTC and display the
time to each clinician in that clinician's preferred time (which the
clinician will probably opt to change - imagine a consult with doctors in
different locations). Anything printed on paper should include the time
zone after the time. Yes, this will require changes to the VistA
application, but at the periphery where times are output or input, and
not at the core.
For legacy VistA deployments, there are several choices, and I don't know
enough about VistA to appreciate the effort for each. All techniques
assume knowledge of the timezone for the legacy VistA deployment. A
couple of approaches may be:
1. As part of upgrading to timezone aware VistA, identify and migrate all
time and date fields to UTC.
2. Run the legacy VistA for historical records and when retrieving the
records, either record the timezone, or change the records during export.
Nothing comes for free. We only have choices that we can decide on wiht
due consideration. Otherwise, in line with the tag line on Steve's
posts, we can all vote ourselves more money from the public coffers!
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 02/08/2010 03:35 PM, Steven McPhelan wrote:
> Then how do you address this real situation which has occurred. The
> time is stored in internal FM format with no UTC. Then that database
> is moved to another time zone. Of course the server has the correct
> timezone for it location. So now 2 pm in FM format that was
> originally PT is now 2pm ET but should be 5pm. Have you not altered
> the medical record?
>
> Once the date and time has been imbedded into the VistA database you
> have lost all reference to the original time zone for which that
> record was recorded. In most of these real situations the database
> still serves the original timezone so one would just set the server
> time clock to that original timezone. However, due to growth and
> expansion this same situation has arisen for which you cannot set the
> server back to the original time zone.
>
> As I stated we cannot change the original FM date definition. In this
> global economy we may have clincians making evaluations on patients
> who EMR server is offset by 12 hours from the clinician. There is
> clinical data for which it is absolutely critical to know the absolute
> date and time of the results and not the relative date and time. If
> this is not addressed and if VistA is not totally rewritten, I do not
> see how a single VistA database can service patients in multiple
> timezones without potentially compromising patient care if absolute
> date and times are not recorded.
[KSB] <...snip...>
Sam Habiel
Sam