On 24.01.2017 18:07, Farhan Tariq wrote:
Hello chris,

Yes we are facing the exact behavior as mentioned by you

"2017-01-23 04:59:58 Something happened
2017-01-23 04:59:59 Something happened
2017-01-24 05:00:00 Something happened
2017-01-24 05:00:01 Something happened"

The changes made to set timezone to system default only effective for time.
We are only operating in GMT+5 and shipping tomcat logs to different
solutions including SIEM in real-time. So we are purely depending on tomcat
to write the logs with correct date time at first.

The above is certainly not true, and there is no technical reason why you cannot use a filter between the tomcat log and whatever.
You can probably do that in Java also, if you insist on it.
But why make it simple when it can be complicated, he ?


I will try to play around with suggestion recommended by you and will let
you know about the outcome.

Thanks
Farhan Tariq

On Mon, Jan 23, 2017 at 8:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Farhan,

On 1/21/17 2:20 AM, Farhan Tariq wrote:
hi,

we have tomcat 7.0.68 deployed on linux.

To capture the log in local system timezone using
ExtendedAccessLogValve class we change the following line
"currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"

into "currentTimestampFormat.setTimeZone(TimeZone.getDefault())"

in ElementTimestampStruct class and then compile and replace the
catalina.jar in already deployed tomcat.

Now , The time is sync with the system set time which is GMT+5 but
somehow date is still operating on GMT as date get changed at 05:00
AM ( system time). please help me in this regard to understand why
the above mentioned change have no impact of date field.

Are you saying that at 05:00, the timestamps in your log file look
like this:

2017-01-23 04:59:58 Something happened
2017-01-23 04:59:59 Something happened
2017-01-24 05:00:00 Something happened
2017-01-24 05:00:01 Something happened

?

What does TimeZone.getDefault() return in your environment?

The java.util.Date object in ExtendedAccessLog recons time using only
the epoch time (milliseconds since 1970 in GMT), and always deals with
it as a long integer value. Only the DateFormat should be making any
interpretation at all as to how to format the date.

However, the value of that date only changes once per INTERVAL
milliseconds, and it changes based upon the GMT date. So your
experience is expected given the code.

Your attempt to change the time zone to something non-GMT isn't
compatible with the performance optimizations that have been made to
that class. If you want to completely change the time zone from GMT to
e.g. GMT+5, then you'll need to adjust the epoch time stored in
currentTimestamp by setting it forward by 5 hours.

A single adjustment is not adequate, because the date value coming
from the request for logging will be off by 5 hours each time, and
that value is used to update the cached value.

I don't believe it is going to be easy for you to change the time zone
with such a simple change to your code. You will need to add the
timezone adjustment each time a calculation is performed. For example:

// ExtendedAccessLog.java:217 (tc9/trunk)
             long millis = eds.currentTimestamp.getTime();
             if (date.getTime() > (TZ_ADJ + millis + INTERVAL -1) ||
                     date.getTime() < (TZ_ADJ + millis)) {
                 eds.currentTimestamp.setTime(
                         date.getTime() - (date.getTime() % INTERVAL) +
TZ_ADJ);
                 eds.currentTimestampString =

eds.currentTimestampFormat.format(eds.currentTimestamp);
             }

You will have to set the value of TZ_ADJ to be 5hrs, or you could
compute it from TimeZone.getDefault(). Note that it won't adjust for
DST or anything like that. I'm not sure if that's a problem for you.

I'm curious... what's wrong with GMT?

- -chris

On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko
<knst.koli...@gmail.com> wrote:

2016-12-14 18:48 GMT+03:00 Farhan Tariq
<farhantar...@gmail.com>:
Hello team,

I am not sure why the timezone is explicitly set to GMT in
ExtendedAccessLogValve class? To capture URL encoded parameters
I looking to use this class but need
help
to get time in GMT+5. I am using tomcat 7 on redhat. Any
suggestions?


1. Please read the mailing list rules:
http://tomcat.apache.org/lists.html#tomcat-users

You have not mentioned what exact version of Tomcat you are using
(1.)

2. Use of GMT in ExtendedAccessLogValve is by design.

That valve implements log format specified by "Extended Log File
Format" specification by W3C, and the specification dictates that
the time is in GMT.

http://tomcat.apache.org/tomcat-8.5-doc/config/valve.
html#Extended_Access_Log_Valve

https://www.w3.org/TR/WD-logfile.html


It may be good to implement configurable timezone in
AccessLogValve (currently it uses TimeZone.getDefault()), but I
think that ExtendedAccessLogValve shall remain with GMT.

Best regards, Konstantin Kolinko

---------------------------------------------------------------------


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYhiNaAAoJEBzwKT+lPKRYaIIQAJGxF3VN5tfrgtAiAVRHrbCx
wAlmCqqLQ/KpFTxh8JQiDFzmjvjGR8HXfZO9G1RkVAl5VcVWQ8RK6jizVaS21Wfi
BU5XFWiEz2goV9WpoJF12PUrrUKrvZzMo/n9QIXdWsD/wVFbXnUHPYKhhvIHx8uF
TZJRlB2Wav2oCw0gYNG5yMf/B/2afjptonZux3EUWAZHnKzZzvn9+PKVXHcRUWFj
ovtoCTG0NbRKAHphqFIHyL45V27JnkT14XGn8bhBdIQLhifhWfJVtu70HbBluol8
f80JPMNfB3wTzm+4QTMqTa4ZCYQrrA/s2LPicWJ4vKz0r52jnyKGoPDJKT7oQjEn
/ipBO20kH8PGxBjU64wbCEV1KEyCYq1+b/mnlX98KFJudNd4jk30pXAUuxhP2PHv
40GyGWiJ2GGJpzPuh2df0keUbK11JMk4zsq0lSzzfG1ZJuGrey9Eq9kMA92qAv9R
es17bwoJPLbKDcY5Ilvi/O8kGU1kjRVrE647KK4HlVIdV8CDMcLLN2xZ4luz7pJL
L0FlkCedBvy+sBigXC0TTEJG2RZ2qenOC2hwb81ogSTGZ9AhycrsahqYgbm7x7bS
SC3LCu6NNT2+Si9ZIs5DyzdN1fys0ZbRHyMCSM5BQz81NadY8cYiHSHLPS6gRoB8
SyuqhSSaHAqeSZKPp2Fh
=NXSe
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to