Converting $H to UTC for a timezone that is not local (Object Script)
Working on a project where we have a web browser that we have to determine a pickup date/time for a pharmacy in a different time zones.
We store the different time zones with their Daylight and Standard offsets.
We have a object script method that figures out the the pickup date/time for a particular pharmacy in their local time zone but the data is being returned in the $H format.
We now need to return it in a UTC format. I see different methods but don't see a method that will change the $H into a UTC for a different timezone otherwise than the local timezone.
I know I can figure a way around it but I was wondering if anyone has found that Intersystems has a method that will do it for you?
Thanks,
Kris Roberts
$Horolog itself does not contain information about timezone, it's just date and time
if you need to make it to another timezone, you can just add or subtract difference
I would look at the %Library.PosixTime (%PosixTime) class. I have used this for similar functions in the past.
https://docs.intersystems.com/irisforhealthlatest/csp/documatic/%25CSP.D...
I will log look the documentation.
Thanks
One more question Rich,
I tried reading the %Libraray.PosixTime class information. I thought that the PosixTime was the days in seconds since Jan 1, 1970 but I think I am missing something. The PosixTime is in seconds so I was thinking I could....
Starting a cold or something so my mind might not be thinking clearly.
Thanks
Correct $H does not have a timezone, however I didn't explain it well that when we figure out the pickup date/time for a pharmacy we would have the timeszone the pharmacy resides in.
So if we figure out the pickup date/time in the $H I then need to convert it to a UTC but for a particular timezone not the locale timezone.
Thanks,
Your time zone is taken from your settings in the underlying operating system
$ZTZ shows the offset from UTC. You can set it to whatever you need.
but ATTENTION this affects $H for the whole IRIS instance !!!
take a serious look into documentation on mostly not wanted the side effects
Robert, it sounds strange, but... Setting the Time Zone
IMHO, $ztimezone setting is dangerous not for its system-wide effect (which it hasn't) but mostly due to its exclusions and anomalies, despite they are accurately listed in docs.
Ah, some improvements.
I personally always used UTC since the introduction of ENSEMBLE (ages back)
Ok. I will look at that.
Thanks
Thanks I can't use the $ZTZ to change the UTC. The server is going to have traffic from many different locations so can't change the server setup.
You can change the Timezone system variable
// for example EST (Eastern Standard Time, 5 hours behind UTC) set $ztz = 300 // you can even consider daylight saving // for example CET (Central European Time, 1 hour ahead of UTC) #define DSTOFFSET -60 #; -60=CET, 300=EST #define LOCALZONE -60 set $ztz = $$$LOCALZONE+$s($system.Util.IsDST():$$$DSTOFFSET,1:0)
Setting $ZTZ affects the current job only (the job, which sets $ztz), so there is no danger for other processes.
Ok. Thanks
ok. Thank you
What about REST services or web apps? Isn't there one process possibly serving several clients' requests?
Shouldn't be a problem, $ZTZ isn't the only thing you can change.
Whatever value or setting you change, $namespace, $zeof, $horolog, etc. you have to consider a simple rule, if you change things (which can be used by subsequent routines, methods, etc.) for your own use, then after using them, you have to restore them to their original value. That's all.
YouRESTorWHATEVERmethod() { set oldZTZ=$ztz set $ztz=<your preferred value> ... set $ztz=oldZTZ return }
Good to thought.
Thanks