New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezone information for America/Sao_Paulo wrong #5245

Closed
kikoreis opened this Issue Oct 27, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@kikoreis

kikoreis commented Oct 27, 2018

Expected Behavior

The timezone America/Sao_Paulo is currently at UTC-3. This was a change from the originally planned timezone defined in 2017 (which by now would have had DST kick in, putting us at UTC-2); on Ubuntu the change forced an update in the system timezones which happened about 2 montths ago.

On the local system, here is what I see:

root@bdillogger:~# TZ=America/Sao_Paulo date
Sáb Out 27 14:42:10 -03 2018

I believe the Java timezone is also correct, because a test program that does

  LocalTime localTime = LocalTime.now();
  System.out.println(localTime);

Shows me 14:43:13.023 with an offset of -180s.

My user is configured to use the TZ "Sao_Paulo", and my server.conf has:

root_timezone = America/Sao_Paulo

So my assumption is that Searches and the System Overview page should be showing the right timezone offset, at -0300.

Current Behavior

But they are not, and instead are at -0200. If I do a search, a message with the following timestamp:

2018-10-27T17:39:11.209Z

Is displayed in local time as:

2018-10-27 15:39:11.209

which is -0200. The overview page confirms this:

User kiko:
2018-10-27 15:46:29 -02:00
Your web browser:
2018-10-27 14:46:29 -03:00
Graylog server:
2018-10-27 15:46:29 -02:00

I'm trying to figure out where Graylog is getting this value of -0200. Perhaps my tzdb.dat is wrong, but wouldn't that cause my test program to print the wrong time too?

Steps to Reproduce (for bugs)

  1. Configure the America/Sao_Paulo timezone for a user
  2. Go to Graylog's System/Overview page
  3. See -0200 for the user.

Your Environment

  • Graylog Version: 2.4.6-1
  • Elasticsearch Version: 5.6.12
  • MongoDB Version: 3.6.8
  • Operating System: Ubuntu 16.04 LTS with latest updates applied
  • Browser version: Any recent FF/Chromium

@edmundoa edmundoa added the bug label Oct 29, 2018

@edmundoa edmundoa self-assigned this Oct 29, 2018

@edmundoa edmundoa added this to the 2.5.0 milestone Oct 29, 2018

edmundoa added a commit that referenced this issue Oct 29, 2018

Upgrade moment and moment-timezone
This updates the time zone database we use in the web interface, fixing
some incorrect time zones, including #5245.

@jalogisch jalogisch added the triaged label Oct 29, 2018

dennisoelkers added a commit that referenced this issue Oct 30, 2018

Upgrade moment and moment-timezone (#5247)
This updates the time zone database we use in the web interface, fixing
some incorrect time zones, including #5245.
@kikoreis

This comment has been minimized.

kikoreis commented Oct 31, 2018

The commit answered my original question -- this is due to the moment and moment-timezone packages which the UI depends on. Is it possible to update them manually in an installed Graylog?

@edmundoa

This comment has been minimized.

Member

edmundoa commented Nov 1, 2018

@kikoreis No, it is unfortunately not possible to update them manually, at least not without rebuilding the whole web interface. I'm afraid you will have to wait until 2.5 is out to get this issue resolved.

In the meantime you could workaround the issue by using UTC-3 as time zone.

edmundoa added a commit that referenced this issue Nov 2, 2018

Upgrade moment and moment-timezone
This updates the time zone database we use in the web interface, fixing
some incorrect time zones, including #5245.

Backported from 2081b2c.

bernd added a commit that referenced this issue Nov 6, 2018

Upgrade moment and moment-timezone (#5260)
* Upgrade moment and moment-timezone

This updates the time zone database we use in the web interface, fixing
some incorrect time zones, including #5245.

Backported from 2081b2c.

* Update module ids after upgrade
@bernd

This comment has been minimized.

Member

bernd commented Nov 6, 2018

This will be fixed in the upcoming 2.5 release.

@bernd bernd closed this Nov 6, 2018

@kikoreis

This comment has been minimized.

kikoreis commented Nov 6, 2018

Ironically, this Sunday DST kicked in and this bug no longer occurs. I think the model Graylog is using, however, is going to trigger many DST problems over time, as the timezone database updates relatively frequently, and Graylog itself can't pick up system updates. Should I file a new bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment