Run servers in one machine in different timezone - java

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.

Related

Why we need to update time zone information of jdk/jre?

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.

Different current time produces through XSLT and Java

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.

How to check if current phones date is today or not [duplicate]

This question already has an answer here:
I want to get current time in Java but without the Internet and without the system time
(1 answer)
Closed 7 years ago.
I need to make sure that in my client application the user doesn't dramatically change the machine date (e.g. bringing it to 1 month before).
To the best of my knowledge, the best way to check the current time in Java is
System.currentTimeInMillis()
How can I make sure that this is the correct date, in a multiplatform environment (either Windows, Linux, Mac, etc.)?
No connection to remote servers available, nor to the internet. Also, at startup time the time could be already tampered. I just need to check the time for internal biz logic purpose, not to set anything.
Radio Clock
Obtain a radio clock with a USB connection for output of current time synchronized by a time code transmitted by a radio transmitter connected to a time standard such as an atomic clock. Similarly, a receiver of GPS signals could also capture the time signal.
The Meinberg Global company, at least, offers several such devices.
Sundial
Position a sundial outside a window. Attach a webcam to the computer in question. Position the webcam in the window. Write an app to interpret the time of day from current image of the sundial. Caveat: Not applicable in Seattle.
Black Box, No Inputs = No Go
More seriously, if you do not trust the system time, you have no access to a time server, and you cannot ask the user for current time, I cannot imagine any solution. You have a black box with no inputs. The radio clock via USB is adding such an input.
Wikipedia has an article on Clock synchronization.
If this is for "demo period" purposes, and you're worried the user might disallow NTP requests (or shut down Internet access), you're out of luck. You might try to detect clues of tampering with time (like files created in the future, or starting the application at a time that is earlier than the previous run's recorded finish time), or you can measure usage time as opposed to period of use (i.e. instead of giving the users 30 days of free usage, you can give them 12 hours of application time, however they break it down), as you can confidently measure time spent inside your application.
Or, you could trust your users. Some might be pirates, but piracy is often a thing of convenience, and most people will not bother changing the clock just to be able to use your software. (This, of course, only applies to some applications; you don't want to trust users if it's a banking or bookkeeping app, for example.)
The solution is nothing related to java. What common solution for this is using NTP server, and configure the system/OS to always synchronize its time with NTP remote server. NTP also used to synchronize the clocks of servers in a cluster. For more information, You can consult http://www.ntp.org/ntpfaq/NTP-s-def.htm

Fetching JVM timezone on Linux Box

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

Time zone is not working properly in windows server

If run this code in windows machine, its works properly:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
System.out.println(sdf.format(new Date()));
It shows date & time same as clock, but the same code if I run on Windows Server it's showing -2hrs of clock time.
I tried by the setting the timezone as,
TimeZone timeZone = TimeZone.getTimeZone("Europe/Vienna");
sdf.setTimeZone(timeZone);
Then, it shows same as clock time.
My doubt is why is it not taking the clock time zone by default in Windows Server.
It should always take the time zone of the running machine but in some case it fails as reported here and here. If you are sure that your server time zone is correct but Java uses a different one, you can force a default time zone of your choice from the command line:
-Duser.timezone="YOUR_TIME_ZONE_HERE"
or by code. You can also try with the Timezone Updater Tool by Oracle.
To see the time zone used by Java:
System.out.println(TimeZone.getDefault());
Time zone settings have no effect on a time value as the computer sees it. See my answer here for details. So long as the system time is set properly (regardless of time zone) and you don't need to display the time as text or parse the time from text, java will have no trouble and its calculations will be correct. If you do need to display/parse a time value, setting the default time zone is safe and it won't effect how times are stored, except of course Java will use that time zone to parse text representations of time that don't explicitly specify the time zone (like if you used the SimpleDateFormat in your example to parse, since the format string doesn't include the time zone).
As for why Java has this problem on your server box but not your desktop box, what version of Windows Server is it, and what version Java is running on the server? My guess is that the JVM can't unambiguously identify the OS version and therefore can't know for sure how to get the local time zone, so uses UTC as a fallback. Try updating your java version to the latest.
Another possibly is that the time zone on the server is set on a per-user basis. Verify that the time zone for the user/process that is running the app on the server is set properly.
There is a bug open at Oracle about that problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044727. Basically it's because Java pulls the timezone out of the registry. And Windows saves it in HKLocalMachine, which is not the Client time but the time of the machine.
I had this issue after upgrading from 2003 server to 2008 server. Java keeps using GMT timezone instead of Windows Timezone setting. The solution is simple, go to Windows control panel and change to a different Timezone(whatever timezone is fine), then change it back. Took me hours to figure it out but it worked as charm.
My thought: the change triggerred something in Java, which correct the issue.

Categories

Resources