I am running:
SAPBC 4.6 (IS 4.6) with patches (SAPBC references) 520423 (SR1) and 516504 (running IS as a win2000 service)
JDK 1.2.2
Win 2000
I have been using pub.date:currentDate with the pattern yyyy MM dd HH:mm:ss SSS and no other Service In settings. My assumption is that the time should be based upon the time of the box that SAPBC (IS) is running on and up until Sunday 25th this seems to have been the case.
The returned date/time is then used to timestamp a log entry written to a flat file using a java buffered writer service (based on sample.IO.utils.fileWriter java services) that appends data to a file thus giving me a history of the running of the process.
I have a scheduled task in SAP that calls SAPBC (IS) at 04.30 am every day. Up to and including Saturday 24th August, the timestamp in the log has been correct (well, give or take a bit because the different servers are never on the same time). From Sunday 25th August onwards, the time has been reported in the log file as an hour ahead of the actual time and when I look at the SAP logs, the run time is still 04.30 (am). The Win2000 box that SAPBC (IS) runs on is at the local time and has not been changed.
For example: dates in yyyy/mm/dd (I’m in Melbourne, Australia)
So anyone got any ideas? I have read the BuiltInServicesGuide and cannot see anything that could explain this but I could be missing something very simple. Do I need to do anything else?
Could it be that for some reason SAPBC (IS) thinks that summer time has arrived here in Australia?
pub.date:currentDate is implemented in Java and Java relies on the underlying OS for date/time and DST settings. An update of the current time, and possibly the timezone, on the Win2K box should correct things.
Hey! We have the same problem. We run webMethods in Australia too (in Sydney), only we run Linux. There definitely something the matter with either the VM, or with webMethods - the OS has the correct time.
Following a message from someone at wM in Australia, I have run a java service that tests the JVM. If the author agrees I’ll post it here, otherwise you’ll have to write your own using TimeZone and Calendar. (A question for the service author: can I post your service here for others to use?)
Here are my results following some testing using various installed JVMs as follows:
When I run with the JVM delivered with SAPBC (IS) Developer, it gives me the correct time.
When I run with the JVM delivered with SAPBC (IS) Server, it gives me the incorrect time.
When I run with the JDK JVM (Sun 1.2.2_008), it gives me the incorrect time.
Looks like the JVM is cactus.
What/which JVM/s are you using Sonam?
My JDK is Sun 1.2.2_008 as my understanding is that because of namespace restrictions, it is not recommended to go to Sun 1.3 and above.
A general question to thelist: what/which version/s is/are recommended that will not have the dates for Australian Summer Time set to those for the year that the Olympics were in Sydney, when Summer time started two months early in some places so as to allow for slightly (!) better TV times?
Many thanks to everyone for any help with this.
Atholl
PS I’m glad that wmusers is back on the air again after the short interlue: a marvellous source of knowledge!
Has anyone been able to correct this problem on their machines? Does setting the GMT to Casablanca help?
We are running W2K with the system clock set to GMT (no daylight savings), but the jvm (1.3) shows the time as GMT+1. This causes my bat files to show a different time than my Flow services.
Hi
I also faced the same problem. I am running Is 4.6 on windows 2000.
My system time is set as GMT.When I am running pub.date:currentDate with the pattern yyyyMMddHHmm, it gives me time which is one hour ahead.
For e.g. my system date is 2003/10/09 04:30 the out put i got from pub.date:currentDate is 200310090530.
To solve this problem what I did is that, I gave the value to the parameter “timeZone” as GMT+0. It looks like that my problem got solved.
The possible reson behind this may be that by default pub.date:currentDate might be using GMT+1.