Menu
▾
▴
Re: [opennms-devel] Problems with timestamp conversion.
|
From: Garth M. <gar...@ne...> - 2012-04-16 00:04:18
|
1.10.0-2 according to dpkg.
On 13/04/12 1:05 AM, Seth Leger wrote:
> Hi Garth,
>
> Which version of OpenNMS are you using? I recently fixed a timestamp
> parsing bug and wondered if this is related.
>
> Seth Leger
> The OpenNMS Group
>
>
> On 04/12/2012 12:43 AM, Garth Mollett wrote:
>> This may actually be a bug in the JVM (Sun/Oralce 1.7.0) or the Linux
>> distribution TZ data files (Debian 6.0.4), but it is impacting OpenNMS.
>>
>> After upgrading to 1.10 we noticed all outages were starting at 20hrs.
>> The time in the webUI, the time on the machine, the time returned by
>> Date() in java and the time returned by now() in postgresql were all
>> correct.
>>
>> Looking deeper the times in the outages tables were all out by 20hrs.
>>
>> So I decided to investigate where these times were coming from.
>>
>> Java is not my native language and I have not looked at the OpenNMS
>> internals before, so apologies if this is wrong or slightly off somewhere:
>>
>> It appears opennms uses Date() to get the current local time at the time
>> of an outage/event and then converts it to GMT to store in memory, but
>> is converted back to local time when it used (or written to the outages
>> table in the DB).
>>
>> Looking at src/main/java/org/opennms/netmgt/EventConstants.java there is
>> the following two functions (erm.. methods..) that the time is passed
>> through (sorry pasting this in email is going to garble the formating):
>>
>> 1133 static final ThreadLocal<DateFormat> FORMATTER_LONG_GMT = new
>> ThreadLocal<DateFormat>() {
>> 1134 protected synchronized DateFormat initialValue() {
>> 1135 final DateFormat formatter =
>> DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.LONG);
>> 1136 formatter.setLenient(true);
>> 1137 formatter.setTimeZone(TimeZone.getTimeZone("GMT"));
>> 1138 return formatter;
>> 1139 }
>> 1140 };
>> 1141
>>
>> and
>>
>> 1104 static final ThreadLocal<DateFormat> FORMATTER_LONG = new
>> ThreadLocal<DateFormat>() {
>> 1105 protected synchronized DateFormat initialValue() {
>> 1106 final DateFormat formatter =
>> DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.LONG);
>> 1107 formatter.setLenient(true);
>> 1108 return formatter;
>> 1109 }
>> 1110 };
>>
>>
>> So, constructing a small test program like the following:
>>
>> import java.util.*;
>> import java.text.DateFormat;
>>
>> public class DateTest {
>> static final ThreadLocal<DateFormat> FORMATTER_LONG_GMT = new
>> ThreadLocal<DateFormat>() {
>> protected synchronized DateFormat initialValue() {
>> final DateFormat formatter =
>> DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.LONG);
>> formatter.setLenient(true);
>> formatter.setTimeZone(TimeZone.getTimeZone("GMT"));
>> return formatter;
>> }
>> };
>>
>>
>> static final ThreadLocal<DateFormat> FORMATTER_LONG = new
>> ThreadLocal<DateFormat>() {
>> protected synchronized DateFormat initialValue() {
>> final DateFormat formatter =
>> DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.LONG);
>> formatter.setLenient(true);
>> return formatter;
>> }
>> };
>>
>> public static void main(String[] args) throws Exception {
>> System.out.println("Date (Local): " + new Date());
>> String timestr = FORMATTER_LONG_GMT.get().format(new Date());
>> System.out.println("Date (GMT): " + timestr);
>> System.out.println("Date (Local): " +
>> FORMATTER_LONG.get().parse(timestr));
>> }
>> }
>>
>> And running it, yields some very interesting results.
>> It appears that in our default locale (we are in Sydney), the conversion
>> from GMT->Local time is not adjusting for the timezone.
>>
>> Running it with LANG=C the results are as expected.
>>
>> Observe:
>>
>> gmollett@onms:~$ locale
>> LANG=en_AU.UTF-8
>> LANGUAGE=
>> LC_CTYPE="en_AU.UTF-8"
>> LC_NUMERIC="en_AU.UTF-8"
>> LC_TIME="en_AU.UTF-8"
>> LC_COLLATE="en_AU.UTF-8"
>> LC_MONETARY="en_AU.UTF-8"
>> LC_MESSAGES="en_AU.UTF-8"
>> LC_PAPER="en_AU.UTF-8"
>> LC_NAME="en_AU.UTF-8"
>> LC_ADDRESS="en_AU.UTF-8"
>> LC_TELEPHONE="en_AU.UTF-8"
>> LC_MEASUREMENT="en_AU.UTF-8"
>> LC_IDENTIFICATION="en_AU.UTF-8"
>> LC_ALL=
>>
>> gmollett@onms:~$ java DateTest
>> Date (Local): Thu Apr 12 14:35:06 EST 2012
>> Date (GMT): Thursday, 12 April 2012 4:35:06 AM
>> Date (Local): Thu Apr 12 04:35:06 EST 2012
>>
>> And:
>>
>> gmollett@onms:~$ export LANG=C
>> gmollett@onms:~$ locale
>> LANG=C
>> LANGUAGE=
>> LC_CTYPE="C"
>> LC_NUMERIC="C"
>> LC_TIME="C"
>> LC_COLLATE="C"
>> LC_MONETARY="C"
>> LC_MESSAGES="C"
>> LC_PAPER="C"
>> LC_NAME="C"
>> LC_ADDRESS="C"
>> LC_TELEPHONE="C"
>> LC_MEASUREMENT="C"
>> LC_IDENTIFICATION="C"
>> LC_ALL=
>>
>> gmollett@onms:~$ java DateTest
>> Date (Local): Thu Apr 12 14:37:35 EST 2012
>> Date (GMT): Thursday, April 12, 2012 4:37:35 AM GMT
>> Date (Local): Thu Apr 12 14:37:35 EST 2012
>>
>>
>> And sure enough, running OpenNMS with LANG=C added to the environment,
>> everything works normally again, and the times in the outages table are
>> correct.
>>
>> I will leave this with you guys, please let me know if you want any more
>> information or if there is anything more I can do to help.
>>
>> Thanks,
>> Garth.
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Please read the OpenNMS Mailing List FAQ:
>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>
>> opennms-devel mailing list
>>
>> To *unsubscribe* or change your subscription options, see the bottom of this page:
>> https://lists.sourceforge.net/lists/listinfo/opennms-devel
>>
>
|