change -Duser.timezone at liferay-ce-portal-tomcat bundle

[Jakub Bebjak, modifié il y a 7 années.]

Hello,
I would like to change -Duser.timezone in bundle liferay-ce-portal-tomcat-7.0-ga3-20160804222206210.zip. Im using Eclipse IDE.
I changed it on multiple locations like setenv.sh, catalina.sh, ... but on every tomcat start is changed back to default GMT.

What Im doing wrong? Thanx.

[Olaf Kock, modifié il y a 7 années.]

Jakub Bebjak:

Hello,
I would like to change -Duser.timezone in bundle liferay-ce-portal-tomcat-7.0-ga3-20160804222206210.zip. Im using Eclipse IDE.
I changed it on multiple locations like setenv.sh, catalina.sh, ... but on every tomcat start is changed back to default GMT.

Eclipse / Liferay IDE does not use the shell-scripts to start tomcat. Instead, double click the server name in eclipse's "Servers" View, which will open the properties page for the server that it shall start. That's where you configure the settings for starting from within the IDE.

Alternatively, you can configure it as you do, start externally through the shell, and connect your debugger to the running process.

Go with Jorge's and David's recommendations. I'll leave my answer here for reference in case someone needs to change other values and wonders why setenv.sh doesn't work. I religiously run servers on UTC myself - I must have given this answer in trance, not realizing what I'm doing.

[Jorge Díaz, modifié il y a 7 années.]

Jakub Bebjak:

I would like to change -Duser.timezone in bundle liferay-ce-portal-tomcat-7.0-ga3-20160804222206210.zip. Im using Eclipse IDE.

It is not a good idea to change user.timezone at JVM, it can cause unexpected issues, see LPS-68408
If you want to change the timezone, set it inside Liferay. You can set it at instance level or at user level:

• Control Panel -> Portal Settings -> Display Settings -> Time Zone is to set the default portal instance time zone.
• Control Panel -> Users -> Display Settings -> Time Zone is to set the default user's time zone. A portal may reside in a different time zone from where the user is using.

If you want to change timezone in log files, you can set it in log4j configuration, see: http://stackoverflow.com/questions/1785725/specify-time-zone-of-log4js-date

[Jakub Bebjak, modifié il y a 7 années.]

I tried all your solutions, but no change...
I would like to change value of this argument

24-Feb-2017 14:09:35.533 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Duser.timezone=GMT

to

-Duser.timezone=Europe/Bratislava

After restart Eclipse server setting -Duser.timezone=Europe/Bratislava was changed to defaults -Duser.timezone=GMT, and I used this portal-log4j-ext.xml placed $TOMCAT_HOME/webapps/ROOT/WEB-INF/classes/META-INF

<!--?xml version="1.0"?-->


<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
	<appender name="stdout" class="org.apache.log4j.ConsoleAppender">
		<layout class="org.apache.log4j.EnhancedPatternLayout">
			<param name="ConversionPattern" value="%d{}{Europe/Bratislava} %p [%c] - %m%n">
		</layout>
	</appender>

</log4j:configuration>

Do you have another suggestions?

[David H Nebinger, modifié il y a 7 années.]

Yes, don't do it.

There are a lot of good reasons why Liferay uses GMT for the low-level data stores. One significant reason is that it eliminates issued when converting to timezones.

Instead you should just go into your company config in the control panel and choose the default timezone to use. This has the effect of reporting timezones in a user-friendly way yet still keep the system at GMT the way it likes it.

[Jorge Díaz, modifié il y a 7 années.]

Hi Jakub,

About log configuration, try using

value="%d{ABSOLUTE}{TIMEZONE} ......

for example using "Europe/Bratislava"

<layout class="org.apache.log4j.EnhancedPatternLayout">
<param name="ConversionPattern" value="%d{ABSOLUTE}{Europe/Bratislava} %-5p [%t][%c{1}:%L] %m%n"></layout>

Try also using "GMT+1" or "Europe/Berlin" to discard other issues.

As I said in my previous message, don't change user.timezone configuration at JVM level. IF you need to change it, try modifying log configuration and Liferay setting in case it is necessary.

[Andrew Jardine, modifié il y a 7 années.]

I'm not sure if this is the same issue I ran into a while back, ...Bit was a looooooong time ago now, but I remember having to change something in the system-ext.properties once.

#
# Set the default time zone used by Liferay. This time zone is no longer set
# at the VM level. See LEP-2584.
#
user.timezone=UTC

[Jorge Díaz, modifié il y a 7 années.]

Andrew Jardine:

I'm not sure if this is the same issue I ran into a while back, ...Bit was a looooooong time ago now, but I remember having to change something in the system-ext.properties once.

You can change timezone there but as I said in my previous comment, you shouldn't modify it.
Leave timezone in GMT or UTC and change it in Liferay configuration or Log4j cfg.

If you change timezone at java JVM level, you can have unexpected issues:

• https://issues.liferay.com/browse/LPS-68408
• https://issues.liferay.com/browse/LPS-58512
• https://issues.liferay.com/browse/LPS-57986
• https://issues.liferay.com/browse/LPS-54319
• https://issues.liferay.com/browse/LPS-33526

[Andrew Jardine, modifié il y a 7 années.]

Hi Jorge,

Yes, it's been very clear on this thread that the Liferay staff don't recommend making the changes at the properties or at the jvm level settings. Sometimes I think though that you guys forget that there are also situations where people using your product have no choice -- be it because they are trying to use it in a way that Liferay hadn't accounted for, or (more often) because a client/project manager/"architect" etc INSISTS that they know better and want it done a certain way.

So -- we hear you , but by the same token it doesn't hurt to provide all the options -- and then strongly recommend (as you have) the one that Liferay would advise.

[David H Nebinger, modifié il y a 7 années.]

Andrew Jardine:

Sometimes I think though that you guys forget that there are also situations where people using your product have no choice -- be it because they are trying to use it in a way that Liferay hadn't accounted for, or (more often) because a client/project manager/"architect" etc INSISTS that they know better and want it done a certain way.

Andrew, you're my friend, so please accept this knowing that I am not trying to attack you on this...

But, you are totally wrong here. There is a difference between setting the timezone at the JVM level and setting a company default timezone or a user default timezone.

The former ensures that all timestamps stored in the database are easily transformed into any view-specific timezone because converting from GMT is easy, whereas converting between timezones is hard.

Liferay depends on and relies on the use of GMT at the server level, hence all of the bugs referenced in this thread that point to huge potential issues by changing.

What most people get wrong, including those clients, project managers and architects, is that Liferay has default timezones assignable at the company level as well as defaults at the user level. You can easily set your company timezone to be CMT or anything else that is appropriate and users hitting the site will see times appropriately rendered.

But what we need to focus everyone on is that Liferay has a real dependency on GMT at the server level and regardless what someone thinks they know, they open themselves up to huge issues if they do attempt a change.

New clients, new project managers and new architects coming to this thread need to get the message that changing the server timezone is simply a really, really bad idea, regardless what they think they know.

For Liferay 6 EE customers or Liferay DXP customers that open tickets complaining about issues after they've changed the timezone? I guarantee the first (and probably only) response they're going to get is that they need to switch back to GMT at the server. It just is what it is.

The only argument, to me, that would even hold water on this is from folks trying to report out of the Liferay database, but even that argument is weak because any reporting tool worth it's salt will support the timezone adjustments from GMT.

But other than that, there's simply not a winnable argument where it makes any sense to go against the Liferay standard of GMT at the server JVM level.

[Andrew Jardine, modifié il y a 7 années.]

FINALLY 10 minutes to get back here to post a reply.

Yes David, we are friends -- but our friendship must be new because if we were old friends you would know by now that I am ALWAYS right ;). Hahah sorry, couldn't resist. To add to this, friends or not, if I post something wrong or stupid I expect the same "short and sweet" answers as everyone else. I've been consulting long enough to have skin like an alligator. It's not that my feelings can't get hurt, it's that I have mastered crying in private ;)

Now, back to the topic at hand. I first answered solely because they question was out there -- but I am not curious about a few things you said. First and foremost --

Liferay depends on and relies on the use of GMT at the server level, hence all of the bugs referenced in this thread that point to huge potential issues by changing.

Can you elaborate on this for me? I usually change the GMT setting when I am setting up a bundle. For me, the reason has always been that when I am looking at log files, I hate to have to try to do the GMT conversion in my head. I like the timestamps to be reflective of my timezone (america/toronto) -- but I never thought that I was actually breaking something under the covers!

What is the dependency that LR has on GMT? and what can go terribly wrong by changing it?

[David H Nebinger, modifié il y a 7 années.]

Jorge posted a list of JIRA tickets all related to using non-GMT in the portal. Those may or may not affect every deployment every time, but the fact that they exist indicates a dependency on GMT at the server level that shouldn't be ignored.

I like the idea here about adjusting the logs for timezone, but honestly it never really bothered me that much that the timestamps were in GMT...

[Jakub Bebjak, modifié il y a 7 années.]

Thanx Jorge,
I edited log4j.properties with these variations:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE}{Europe/Bratislava} %-5p [%t][%c{1}:%L] %m%n
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE}{Europe/Berlin} %-5p [%t][%c{1}:%L] %m%n
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE}{GMT+1} %-5p [%t][%c{1}:%L] %m%n

but unsuccessfully...

I need change timezone on my localhost because, after every theme deploy during development I'm getting these never ending unnecessary logs for every single file in project

  Warning: images\social\follow.png modified in the future.
  Warning: images\social\follower.png modified in the future.
  Warning: images\social\following.png modified in the future.
...

But still I can change timezone via Run Configurations in Eclipse...

[David H Nebinger, modifié il y a 7 années.]

That has nothing to do with the timezone settings, Jakub.

You're getting that error because your local system timestamp is out of sync with the server you are deploying to. Sync up your system clocks and this message will go away.

[Thomas Kellerer, modifié il y a 6 années.]

David H Nebinger:

That has nothing to do with the timezone settings, Jakub.

This has everything to do with the timezone setting. If the JVM timezone is set to something different then the computer's timezone you will see this error. When I save my files, the operating system uses the computer's time to set the "modified" time of the file. However as the timezone of the Liferay portal is changed to something different then the computer's timezone, the JVM "thinks" it's a different time. And if you are ahead of UTC, this will result in that log message.

David H Nebinger:

You're getting that error because your local system timestamp is out of sync with the server you are deploying to. Sync up your system clocks and this message will go away.

I develop and run Liferay on the same computer - my laptop.
There is nothing to "sync" up. This is an effect of forcing the JVM to use a different time then the computer.

[David H Nebinger, modifié il y a 6 années.]

So this calls into question the time configuration for your laptop; is the correct timezone set in the date/time control panel?

These are not new problems... UDT/GMT and local timezone conversions have long been confusing. If apps and the system get out of sync, weird side effects start popping up...








Come meet me at the 2017 LSNA!

[Thomas Metten, modifié il y a 6 années.]

David H Nebinger:

So this calls into question the time configuration for your laptop; is the correct timezone set in the date/time control panel?

Do you imply that we should set the timezone of our laptops to GMT / UTC as well when we are developing in Liferay?

I'm currently digging into developing themes with the new theme-generator. When I leave the JVM's user.timezone setting on GMT, and my laptop's timezone on CET or Europe/Brussels (as this is the correct timezone for Belgium) I'm constantly getting "<file> modified in the future." warnings.
This is because my own timezone CET, is ahead of GMT.

I suppose for Liferay developers developing from a timezone before GMT, this doesn't pose a problem, because their laptop dates will always be in the past compared to GMT.

[Andrew Jardine, modifié il y a 6 années.]

I don't think they question was really whether or not it was ok to make alterations to your local machine as a developer to suit your needs -- I think it was more about what to do on the servers. I am constantly doing things to my local dev environment that I would never do to a production server for example.

As a matter of interest, I believe the lions share of the developers at Liferay are actually in Europe and farther east. So I suspect that a lot of the staff also have the same UTC +XXX situation you do.

[David H Nebinger, modifié il y a 6 années.]

Right.

On your local system, you have your system set to some timezone (hopefully correct time too). When you run tomcat locally using GMT as the timezone, everything should be fine.

In the upper lanes, you will also have tomcat running as GMT and there, too, everything will be fine.

I'm constantly getting "<file> modified in the future." warnings.

This happens not when timezones are off, but when the actual time is off. If the clock on the system I'm deploying to is behind the clock on the system I build on, the system will see files as modified in the future. This is a system level report and has nothing to do with the timezone settings of either system, it is due to clock skew between the systems.

If you synchronize your clocks using an NTP server, you should see the modified in the future warning go away.








Come meet me at Devcon 2017 or 2017 LSNA!