I have two services running on separate machine. I'm seeing strange behavior in the boxes when generating the current time. The current time is being generated differently.
In one machine it's being done in XSLT using current-dateTime() function e.g.
<xsl:variable name="dateNow" select="format-dateTime(adjust-dateTime-to-timezone(current-dateTime()), '[Y0001]-[M01]-[D01]T[H01]:[m01]:[s01]')"/>
In the second machine, the current time is being generated in Java code using Joda Time e.g.DateTime.now()
Why is box one 1h ahead of box two?
I've checked the current time in and the time zone in both machine. They are the same.
Update:
Originally I thought it was time zone issue which is why I added adjust-dateTime-to-timezone . adjust-dateTime-to-timezone has no effect.
When you say "different boxes" I assume you mean different computers. The most likely explanation is that the default timezone is set differently on the two machines.
Related
I know that is required because of changes that occurs after the release of the jdk/jre, but why don't get those informations from the server?
As "from the server" i mean from OS. The question is: "Why doesn't Java use the time zone system from the operating system instead of having its own copy of the time zone database"?
Here is my rough understanding. I believe it should at least give you the main reasons.
When Java was designed in the 1990s, a main design goal was that your Java program should be write once run anywhere, popularly abbreviated WORA. At that time cross-platform programs were not that commonplace. Porting your Windows program to a Mac or vice versa required quite some effort. Sun, the company that developed Java, was selling an operating system called Solaris, a Unix variant that not that many wanted to port to or from.
Different operating systems have different time zone data: different structure, different names for the time zones, different amounts of detail. Windows, for example, hasn’t got the full history of offsets for all time zones. What Mac and Unix had in the 1990s I don’t know. There were many Unix variants back then, and I am not even sure whether they all had built-in time zone information.
So relying on the operating system would mean that a program doing for example TimeZone.getTimeZone("America/Sao_Paulo") (using the time zone class from back then, now long outdated) would not be portable because on another operating system the time zone would not be called that. The write once run anywhere idea would be seriously harmed.
I suppose that this was the main reason for choosing that Java needed to have its own built-in time zone database, the same on all operating systems. I also believe that the choice of the Olson database, also known as tzdata, the zoneinfo database or IANA time zone database, was rather obvious. And from this choice came also the need for being able to update the timezone data, since the database is constantly evolving, especially since politicians around the globe are constantly (and eagerly, it would appear) deciding on new time zone rules.
Links for comparison:
List of tz database time zones
Windows Default Time Zones
Please notice that the former uses time zone IDs like America/Sao_Paulo, that is the region/city format, while the latter instead uses names like E. South America Standard Time.
I have a distributed system with a server that is written in Java and a Client that is written in C#. I want to do some performance measurements on that system, e.g. "How long does one roundtrip take?" or "What is the time between sending the request and calculating the response value?".
My first attempt was to print timestamps at specific situations on server and client and later calculate the differences between the two timestamps to get the duration.
BUT... when I ran the test, I noticed that sometimes the difference between two timestamps (A-B) was negative, even though timestamp B was created before timestamp A. (one of the timestamps was created on the server, the other one on the client) So I guess that the way the timestamps are created is not a exactly the same.
Does anybody have an idea how I can do that correctly?
I hope that I could explain my problem. If there are any questions, please let me know in the comments.
EDIT: further information about the setup
The C#-client is running on my local PC. The Java-server is running on a virtual machine, which itself is located on my PC.
I am running Three Quartz servers(as java wrapper services) from one Linux Virtual Server machine. My requirement is to run these servers in different time zone in one machine. e.g. Say there are three servers name A, B and C then A should schedule job based on Central Time zone, B should schedule jobs based on Eastern Time zone and so on. Is there any way we could achieve this?
Time zones are but concepts in Unix land. Each system clock should run with UTC, calculating displayed times based on the timezone you configure within the system.
Depending on which software should deal with that, it might be totally sufficient to set the TZ environment variable correctly.
I created three users for three different servers and set the desired time zones in .bashrc file. Say user name is user1 then do the following:
Open file /home/user1/.bashrc usinf any editor.
Modify and enter this line:
export TZ="/usr/share/zoneinfo/{TIMEZONE-DIRECTORY}/{TIMEZONE_FILE}"
Save the file.
Timezone is set for the user now.
Is it possible to get the TIMEZONE set in JVM using a command in Linux? I am trying to fetch this information from a production box where I wouldn't able to deploy any code to check.
JVM makes some statistics about the app available via JMX, and some are available by default, so it's rather likely you will be able to retrieve them from your app, too. You can use jconsole tool to connect to a Java app and read those values. I don't see the clock time being one of them, but you can check the application's startup time, and the uptime. Adding one to the other gives you the current time as the app sees it. You can find both values in jconsole in the "MBeans" tab: in the tree on the left select: java.lang / Runtime / Attributes - they will be called "Uptime" and "StartTime". Uptime is in milliseconds and StartTime is in milliseconds since January 1st, 1970.
PS: If the above doesn't work, you can try to retrieve the time indirectly. The time returned by System.currentTimeMillis() is based on the machine's clock, so it should be the same as returned by any other program that queries the clock, e.g. the command-line date command. One possible deviation would be the possibility of the java application using a different time zone, e.g. due to environment variables set differently than for your command-line program.
no. this is not possible. you cannot get the time set in JVM using a command in linux. for further information run "java" command in command prompt or console and you will see which commands JVM can receive directly
I am starting an application with remote debug and suspend on start turned on.
When I connect remotely to the process, I getting stopped in an uncaught FileNotFoundException in ZoneInfo.getTimeZone()
It is cause by the line: new PatternLayout("[%d{HH:mm:ss}] %-5p: %m%n").
apparently java is not finding timezone for Israel in jre/lib/zi directory.
I appreciate if you know how to fix it.
Thanks.
Edit: It appears the problem is that time zone is defined as "Israel" and Java only have "Asia/Jerusalem" time zone.
How can It be changed on linux machine?
Israeli time zone should be Asia/Jerusalem. I see it under my jre/lib/zi.
I believe that there can be 2 reasons for failure of your program:
this file does not exist on your system.
something is wrong in definition of time zone on your computer.
So,
Check if the file Jerusalem is there
Check what is the default time zone returned by TimeZone.getDefault() and what is configured on control panel.
From what I found so far this is an inconsistency between suse 10 os and java. the os calls the time zone "(GMT+2:00) Israel" while java expects "(GMT+2:00) Jerusalem".
There is a workaround - starting java with the flag -Duser.timezone=Asia/Jerusalem or -Duser.timezone=GMT+2. the second option is not good for daylight savings. more details on this blog.