Skip to main content

Timezones, Glassfish, Two different systems: How do I change the TZ of Glassfish?

13 replies [Last post]
Anonymous

I am developing on my local system (Windows XP) set to the Time Zone in which
I work. I am developing for a system that provides Glassfish in UTC (on the
production server - non-Windows). When I run my Date (and time)
calculations which also are to provide access from any time zone I cannot
test my software to provide similar results as what the production
environment will return.

Is there a way to change the timezone for Glassfish on my local system
without changing the timezone of the whole system?

--
View this message in context: http://www.nabble.com/Timezones%2C-Glassfish%2C-Two-different-systems%3A...
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Marina Vatkina

If this is the case, can you keep the value as a long and convert to/from Date
yourself?

thanks,
-marina

rdblaha1 wrote:
>
> Marina Vatkina wrote:
>
>>I'm wondering how can it work with JDBC and fail with JPA... JPA uses the
>>same
>>JDBC API to get the data from the database...
>>
>>Will using property-based persistence where you modify the Date values
>>when they
>>come from the database solve your problem?
>>
>
>
> I must apologize for listening to partly misleading information from my
> fellow worker. As I am in my beginning days of working with time and dates,
> persistence, and Glassfish I was already working with long values when I
> interfaced with persistence and the database. Using long values I was not
> getting the wrong data as I described it. Because I was seeing what
> appeared to be discrepancies I was prone to believe the problems described
> were the cause. I do apologize for that confusion. What has been said has
> been very useful in learning more about using and establishing a baseline
> that all dates may be established from and compared to.
>
> Once I described to my fellow worker what I was doing and he looked at my
> code he realized that how what he told me was misleading, and what the
> actual problem he faced was; and what I thought was my problem.
>
> What he had told me was when a Date object is passed as a temporal object
> into persistence, persistence in turn converts the Date object to a long.
> It is within this context, either Glassfish or toplink, apparently converts
> the Date object to a long applying the system Timezone on which it resides.
> Since I was already passing in a long I was not truly having the problem
> described. The post from 'matterbury' suggested a user.timezone property
> with Glassfish. I have searched for this without success. If someone
> knows where this property may be accessed, please let me know.
>
> The problem with the Date object conversion to a long by Glassfish or
> toplink still exists. If you have experience in this area, please help.
>
> Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

matterbury
Offline
Joined: 2008-05-01

If you can set properties for the server (*), you could try setting the user.timezone property and restarting it.

(*) I expect you can but I don't know how and mine's not running right now so I can't browse the admin screens.

rvdberg
Offline
Joined: 2009-05-30

These settings can be found in the Glassfish admin console panel under: Configuration --> System settings..
I was struggling with the same problems on my production machine...

You can set the
user.country
user.language
user.timezone

properties here. Restart the application server and then check your settings by requesting a JVM Report found in the 'General' Tab under the 'Application Server' Menuitem.

Worked fine for me, goodluck!

montereyjack
Offline
Joined: 2009-07-27

Thank you for all this useful information. I've just created a account so I can comment.

My JVM Report shows user.timezone=GMT but my print out statements in a couple of web services prints a default time zone that is the same as the timezone on the host itself. I ended up changing the timezone programmatically via TimeZone.setDefault (....) but I found something interesting and perhaps expected. Apparently web applications are threads in the same JVM. I found that changing the timezone in one web service changes the timezone for all.

Back to JVM Report, while my report contains:

...
user.home = /root
user.language = en
user.name = root
user.timezone = GMT
....

I don't see where any of these stuff is set in the adimin console. I don't see it in JVM Options??? Under Configuration->System Properties, I have like zero properties defined?

Any comments?

Thank you.

ipsi
Offline
Joined: 2009-02-04

I'm not sure how much help this will be, but have you considered setting up a virtual machine which will run on the target timezone? In theory, you should be able to get everything set up such that deploying to and developing on that virtual machine is no different to developing on the host operating system, but I haven't actually attempted this myself. Just a thought.

Marina Vatkina

I'm wondering how can it work with JDBC and fail with JPA... JPA uses the same
JDBC API to get the data from the database...

Will using property-based persistence where you modify the Date values when they
come from the database solve your problem?

thanks,
-marina

rdblaha1 wrote:
>
>
> Alex Sherwin wrote:
>
>>The underlying JDK uses the systems time I believe...
>>
>
>
> Thank you Marina and Alex. Your information is helpful. While we have been
> working for several years in Java, and your answers gave a help
> consideration for furthering our time library we have developed, we are
> fairly new to Glassfish and persistence. Prior we were using direct JDBC
> access to our database. The database doesn't care one way or another. It
> just accepts time or dates as long integers that has worked great. However,
> we have intentionally based our numbers placed in the database to be UTC.
>
> The problem we are seeing is that the application server appears to apply
> the system time zone of the environment it is in and perform a conversion
> before it persists the value to the database. Since we continue to use the
> older system in parallel with the new system we are developing. Therefore
> the time value Glassfish persists to the database cannot be read by the
> pre-application server system and return the date and time that is expected.
> The older system is not going to be re-written to guess at what Time Zone
> that Glassfish was in when it persisted the time value to the database.
>
> Because of this I was asking if there is a way to tell Glassfish which Time
> zone I want it to use?
>
> Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdblaha1

Marina Vatkina wrote:
>
> I'm wondering how can it work with JDBC and fail with JPA... JPA uses the
> same
> JDBC API to get the data from the database...
>
> Will using property-based persistence where you modify the Date values
> when they
> come from the database solve your problem?
>

I must apologize for listening to partly misleading information from my
fellow worker. As I am in my beginning days of working with time and dates,
persistence, and Glassfish I was already working with long values when I
interfaced with persistence and the database. Using long values I was not
getting the wrong data as I described it. Because I was seeing what
appeared to be discrepancies I was prone to believe the problems described
were the cause. I do apologize for that confusion. What has been said has
been very useful in learning more about using and establishing a baseline
that all dates may be established from and compared to.

Once I described to my fellow worker what I was doing and he looked at my
code he realized that how what he told me was misleading, and what the
actual problem he faced was; and what I thought was my problem.

What he had told me was when a Date object is passed as a temporal object
into persistence, persistence in turn converts the Date object to a long.
It is within this context, either Glassfish or toplink, apparently converts
the Date object to a long applying the system Timezone on which it resides.
Since I was already passing in a long I was not truly having the problem
described. The post from 'matterbury' suggested a user.timezone property
with Glassfish. I have searched for this without success. If someone
knows where this property may be accessed, please let me know.

The problem with the Date object conversion to a long by Glassfish or
toplink still exists. If you have experience in this area, please help.

Thank you.
--
View this message in context: http://www.nabble.com/Timezones%2C-Glassfish%2C-Two-different-systems%3A...
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Alex Sherwin

The "user.timezone" is a JVM System property, try this:
System.out.println(System.getProperties());

You will see an entry similar to this: user.timezone=America/New_York

Now if you run the same test program with the JVM option:
-Duser.timezone=Pacific/Midway, the output will contain:

user.timezone=Pacific/Midway

You can see the list of timezones your jdk supports with
TimeZone.getAvailableIDs()

rdblaha1 wrote:
> Marina Vatkina wrote:
>
>> I'm wondering how can it work with JDBC and fail with JPA... JPA uses the
>> same
>> JDBC API to get the data from the database...
>>
>> Will using property-based persistence where you modify the Date values
>> when they
>> come from the database solve your problem?
>>
>>
>
> I must apologize for listening to partly misleading information from my
> fellow worker. As I am in my beginning days of working with time and dates,
> persistence, and Glassfish I was already working with long values when I
> interfaced with persistence and the database. Using long values I was not
> getting the wrong data as I described it. Because I was seeing what
> appeared to be discrepancies I was prone to believe the problems described
> were the cause. I do apologize for that confusion. What has been said has
> been very useful in learning more about using and establishing a baseline
> that all dates may be established from and compared to.
>
> Once I described to my fellow worker what I was doing and he looked at my
> code he realized that how what he told me was misleading, and what the
> actual problem he faced was; and what I thought was my problem.
>
> What he had told me was when a Date object is passed as a temporal object
> into persistence, persistence in turn converts the Date object to a long.
> It is within this context, either Glassfish or toplink, apparently converts
> the Date object to a long applying the system Timezone on which it resides.
> Since I was already passing in a long I was not truly having the problem
> described. The post from 'matterbury' suggested a user.timezone property
> with Glassfish. I have searched for this without success. If someone
> knows where this property may be accessed, please let me know.
>
> The problem with the Date object conversion to a long by Glassfish or
> toplink still exists. If you have experience in this area, please help.
>
> Thank you.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Alex Sherwin

The underlying JDK uses the systems time I believe...

However, you can still compare these times appropriately without making
any changes. The java.util.Date object is backed by an epoch timestamp
in millis, which is the same generated in UTC on your production server
and your local timezone on your development machine).

However, since when you create your java.util.Date object on your dev
machine, you're applying a timezone (lets say EST), format its output
with a SimpleDateFormat or something similar, it appears to be different
(but only because the SDF is doing you a favor and displaying it in your
local time).

The times are still the same, just being displayed contextually differently.

You could either compare timestamps with the .getTime() method of
java.util.Date, or instantiate a new java.util.Calendar and force its
time zone like this:

final Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));

You can then set the epoch timestamp on the calendar, and get a new date
object with the getTime() method on java.util.Calendar, which will
return you a Date object in GMT

I'm sure theres plenty of other ways you could accomplish this as well

rdblaha1 wrote:
> I am developing on my local system (Windows XP) set to the Time Zone in which
> I work. I am developing for a system that provides Glassfish in UTC (on the
> production server - non-Windows). When I run my Date (and time)
> calculations which also are to provide access from any time zone I cannot
> test my software to provide similar results as what the production
> environment will return.
>
> Is there a way to change the timezone for Glassfish on my local system
> without changing the timezone of the whole system?
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdblaha1

Alex Sherwin wrote:
>
> The underlying JDK uses the systems time I believe...
>

Thank you Marina and Alex. Your information is helpful. While we have been
working for several years in Java, and your answers gave a help
consideration for furthering our time library we have developed, we are
fairly new to Glassfish and persistence. Prior we were using direct JDBC
access to our database. The database doesn't care one way or another. It
just accepts time or dates as long integers that has worked great. However,
we have intentionally based our numbers placed in the database to be UTC.

The problem we are seeing is that the application server appears to apply
the system time zone of the environment it is in and perform a conversion
before it persists the value to the database. Since we continue to use the
older system in parallel with the new system we are developing. Therefore
the time value Glassfish persists to the database cannot be read by the
pre-application server system and return the date and time that is expected.
The older system is not going to be re-written to guess at what Time Zone
that Glassfish was in when it persisted the time value to the database.

Because of this I was asking if there is a way to tell Glassfish which Time
zone I want it to use?

Thank you.
--
View this message in context: http://www.nabble.com/Timezones%2C-Glassfish%2C-Two-different-systems%3A...
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdblaha1

rdblaha1 wrote:
>
> Because of this I was asking if there is a way to tell Glassfish which
> Time zone I want it to use?
>

And just an observation as I thought about this over the weekend, If each
instance I start of Glassfish cannot have its Timezone set individually then
it would appear that Glassfish is not completely portable, but would be tied
directly to the hardware on the machine on which it resides -thinking
specifically of Windows OS. On a Unix or Linux box I believe you can set an
environment in which Glassfish may be started and within that environment
specify the Timezone for that environment. That is obviously NOT the same
as Glassfish itself controlling its own environment which would be
preferable considering the number of hardware dedicated Windows systems that
exist. Again, just for observation.

My question still is asked, Is there a way to setup Glassfish to control its
own environment with Timezone being included in that controlled environment?

--
View this message in context: http://www.nabble.com/Timezones%2C-Glassfish%2C-Two-different-systems%3A...
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Marina Vatkina

Can you use Calendar instead of Date to construct a date with the expected TZ?

thanks,
-marina

rdblaha1 wrote:
> I am developing on my local system (Windows XP) set to the Time Zone in which
> I work. I am developing for a system that provides Glassfish in UTC (on the
> production server - non-Windows). When I run my Date (and time)
> calculations which also are to provide access from any time zone I cannot
> test my software to provide similar results as what the production
> environment will return.
>
> Is there a way to change the timezone for Glassfish on my local system
> without changing the timezone of the whole system?
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

morcegao
Offline
Joined: 2013-08-27

I solved my problem right now and with the intention of helping others desevolvedores, follow the step by step

type in your glassfish
c: \ glassfish3 \ bin \> asadmin list-jvm-options

see if the list appears
-Duser.timezone = UTC

case does not appear go to the domain.xml file and search for jvm-options and add the command line
-Duser.timezone = Brazil / East substituting the Brazil / East timezone by country

after restart the server and be happy