(note, this is cross-posted with Advantage because of a lack of response from that site)
I get different results when I invoke pub.date:getCurrentDateString from within a flow service, as opposed to invoking it from IS Administrator.
I invoke the pub.date:getCurrentDateString service with the following input:
pattern: HH:mm
timezone:
Assuming the computer clock reads 12:34 (about noon, daylight savings time in Wash D.C.)
When invoked from a flow service I get this result:
12:34 (which is expected, local daylight time)
When invoked from IS Admin I get this result:
16:34 (which happens to be GMT, not local time)
When I provide a timezone=EST, both return 11:34 (GMT-5), which is the correct EST, but I want EDT (GMT-4) (however, there is no such official timezone)
BTW, I am running IS 6.5 SP1 on Windows
The behavior is the same with either the SUN or IBM jre
JAVA_DIR=C:\webMethods6\jvm\win142\jre ( java 1.4.2_07 with SUN’s daylight saving patch applied)
JAVA_DIR=C:\WebSphere60\AppServer\java (java 1.4.2 with IBM’s daylight saving patch applied)
I have no idea why invoking from the “test service with inputs” feature in the IS package management screens. My guess is that there is some value being passed to the timezone field (either GMT or a space) that is not expected.
If you were really, really curious, you coudl write a simple wrapper service that accepted the same parameters and executed a pub.flow:tracePipeline before calling pub.date:getCurrentDateString. That would tell you what is really being passed from the “test service with inputs” feature.
An empty string is being passed when using the “test service with inputs” button within IS Administrator. If one checks the “Include empty values for String Types” box in Developer, you’ll get the same results.
When the timezone is an empty string, or any value that the TimeZone class does not understand, GMT is used as the timezone.
The use of three-letter time zone IDs is deprecated, thus you shouldn’t use EST. You can use GMT-4:00 or one of the IDs that correspond to the timezone you’re interested in, such as America/New_York.
Hi All,
I experienced the same behavior but in following scenario:
Using WM Developer to test/preview date values we receive on value.
Using test functionality from IS Admin page, we receive dates with the IS server time zone.
Just keep in mind that Developer show dates localized accord to the Regional Settings to the PC where
WM Developer is installed, but if you invoke service via HTTP for example you should receive date correct with right time zone with Developer is confusing, especially if IS Server and Developer are in different time zones.
Glad we could help. One of the reasons I pay attention to the number of new members that join each month is that size does matter when it comes to the number of sets of eyeballs that can read and respond to questions like your.
We still don’t get to everyone’s questions, so if you’re reading this and haven’t jumped in to help someone else with your experiences and knowledge, now is a great time to start.
Also, Advantage is a tremendous resource for webMethods professionals (old pros and newbies alike). I regularly spend time there researching issues, getting the latest docs and sniffing out new tech notes.