Opera shows incorrect date

I am in the U.S. Chicago area. The date here is Tuesday July 21 and the time approximately 4:44 P.M when I started this. I believe that is 21:44 UTC.

When I view the history, for example, having quite recently accessed the website into which I am typing this, the most recent access to opensuse.org using Opera “Version:69.0.3686.49 Opera is up to date Update stream: Stable System: openSUSE Leap 15.1 (x86_64; KDE)” is shown as being “Today - Monday, July 20, 2020”. Other browsers which also show dates for history entries for today, show the correct date. So it would hopefully not be an issue with the system date. Software updates for the system as a whole are ostensibly up to date. I’ve looked for some setting within Opera to adjust the date or time reference; if there is such a thing, I’ve missed it.

Obviously this is not a big deal. I just wanted to report it.\

Have you checked the BIOS date/time is correct? In YaST Date/Time, is the timezone set, are you using UTC time in the BIOS? If so, is the box checked to use UTC?

Thanks for your reply. I edited my original post to clarify, but I should also say that the time in the history display within Opera, is the local time. But yes, the BIOS time is UTC, the local timezone is set to Central Time, the standard for the Chicago area and yes, the box in YAST2 is checked to use UTC as the BIOS time. Given that Opera has the correct local time, unless Opera thinks it is on the other side of some “date line”, I would have hoped that it would have the correct date.

I’m not sure where you are checking that.

I stared “opera” and then went to “update and recovery” from the menu. That told me that “opera” is up to date, and that the last check was a few minutes ago. However, it is 2 months since I last started “opera”. In your case, it might be that it has cached the information since the last check, and has not rechecked because that was recent enough.

Sorry, I really don’t know what you are trying to tell me.


  1. The Opera version is available both from “Update and Recovery” from Opera’s menu, and from “Help->About Opera” from Opera’s menu. Comparing those two seems to suggest that the version of Opera I am using is up to date.
  2. The “history” to which I am referring is from the History selection in Opera’s menu. I am sorry if the version of Opera my initial post wasn’t clear. I was just trying to include the version of Opera that I was using. I suppose that may have seemed ambiguous because I included it in the midst of a sentence that was perhaps too long.

When I view Opera’s history for today, for example, not too long after coming to this page, this is the first couple of lines in the main history display look like:

 Today - Monday, July 20, 2020

    22:28  forums.opensuse.org  Leap 15.1 Opera shows incorrect date

So it has the time correct, but the date, which it claims is today’s date, is actually yesterday’s date, at least in my location in the United States, Chicago area.

That’s odd.

I’m in the Chicago area, and not seeing any problem. The opera history is long, but just a list of sites visited, including from back when I was running Leap 15.1.

So what’s the output from:

ls -l /etc/localtime
echo $TZ

I understand what you are going for, but if I visit the “thread” into which I am typing, with Chrome, then Opera, and view the history, this is how the history from Chrome starts:

Today - Wednesday, July 22, 2020

12:15 AM  [openSUSE - Linux OS. The makers' choice for sysadmins, developers and desktop users.](https://www.opensuse.org/)  [www.opensuse.org](http://www.opensuse.org)

this is how the history from Opera starts:

Today - Tuesday, July 21, 2020

    00:16  forums.opensuse.org LEAP 15.1 [Opera shows incorrect date](https://forums.opensuse.org/showthread.php/541972-Opera-shows-incorrect-date)

So unless the two browsers interpret the time zone differently, I would suggest that they should both show the same date.

I just started opera at the command line with


but it did not complain about time. The history times were off (New Zealand time instead of Chicago time), but Opera did not seem bothered.

Does this happen only for “forums.opensuse.org”? Or does it also happen at other sites?

It is consistent within Opera. Naturally since it’s almost like we’re living on Moon 19 of Planet COVID, it’s easy to be preoccupied. But even that and other things combined, only delayed the recognition of the wrong date for a short while. It was one thing if I brought up my browsing history in Opera, executed a search through it, and nothing that was found, was from today. But then when something was from today, the wrong date was rather obvious. I keep around a dozen browsers or so for when I’m testing websites that I’ve built. With those other browsers, I tried visiting some of the same sites that were shown within Opera as being from “today”. In any context where the other browsers show history with a date with some designation such as “Today”, they showed the proper current day’s date. So it seems to have nothing to do with a specific site. I looked through Opera’s setting looking for something that might affect time or date. But I didn’t find anything that seemed to me as though it could have that effect.

I’m out of ideas at this stage.

It looks as if “opera” has two different way to check the time, and they don’t agree. But I don’t know what those ways are.

One way is with the system date used by your running system. Another way would be some sort of online check, but I don’t know if it is doing that.
With a typical openSUSE install, there should be an “ntp” daemon running that keeps your system time synchronized with network servers.

Yup, I’m using NTP; when checked against time.gov it matches ( within an incredibly tiny fraction of a second ) . It’s very strange, especially since whatever it is, only seems to affect Opera!

Stranger still, it affects opera for you, but not for me.

Maybe try creating a new user account, and test whether it happens for that new user.

Thanks. Although ultimately this is no big deal, I somehow have become a bit fascinated by it. None of the system “User start up scripts”, such as those in /etc in my environment, set TZ; nor do any of the “System provided” start up scripts in the User’s directory. I certainly have not edited any of them to remove any setting of TZ. If I set TZ in the shell environment, that clobbers the digital “clock” that’s being used from the panel in KDE. I’ve tried pre-pending the setting of TZ in the individual launcher which is in use by KDE from the panel, for Opera. I’ve tried various GNU and POSIX formats for TZ there. I was naturally hoping that the form that indicates the difference between CST and CDT, and when to apply the difference, would work. It did not. Using the more involved formats for TZ I was able to get the correct date, but the time was skewed, and not by anything that made sense in the Central U.S. Time zone. If I just use something like ‘UTC-x’ in TZ to adjust the time skew, that works. But I have to set to off by an hour or two, compared to what makes sense for Central Time. I’m now in the process of trying to make sure that a command will be executed within the assignment to TZ, to allow a format used with the date command to provide a dynamic offset from UTC to overcome the problem. Using the website based help for Opera, I found no dependence on TZ for Opera. I’ve run Opera from the command line with a “–help” option, but didn’t find anything relevant. I believe the so called chromium package is used within Opera. I’m going to check for any dependence of that on TZ. I was going to go through the Opera config files for me as a User, but your suggestion to create a different User account should be a faster approach. The real “Acid Test” will probably be when I finally install Leap 15.2 AND create a different User account on that, to test this issue. Thanks again!

Yes, I probably would have the same reaction.

If I set TZ in the shell environment, that clobbers the digital “clock” that’s being used from the panel in KDE.

Not really.

If you set it in your shell startup file (such as “.bashrc”, then it will affect the digital clock. But if you manually set it in a “konsole” session, then it will only affect commands started from there.

I believe the so called chromium package is used within Opera. I’m going to check for any dependence of that on TZ.

I don’t think that’s relevant.

Yes, opera is based on chromium. But, as far as I know, it is a self-contained package. It comes with its own copy of whatever it needs from chromium.

To check with the opera on Leap 15.2, I looked at its dependency list (in Yast Software Management). And it only shows a few items such as “/bin/sh” and rpm libraries. By contrast, “falkon” has many dependencies include some with “WebEngine” as part of the name. Those “WebEngine” related packages are the chromium base being used.

Sorry for any misunderstanding, but when it comes to files such as “.bashrc” and the use of Chromium package, I feel we’re actually saying roughly the same things in different ways. I’m thinking the differences might be my use of the term “clobber” and the term “dependency”.

In my comment to which you were responding, when I talked about what happens when TZ is set, let’s say “globally”, or it’s affect on the clock/calendar program which is available within the panel on KDE Plasma which I’m using, I was talking about things I’d actually done and verified.

Also, WRT the usage of the Chromium package by Opera, I believe it is as I thought you indicated, NOT external to Opera. I meant dependency in a different way.

When I wrote my previous comment in this thread, I had already tried:

  1. setting TZ in my “.profile”. That didn’t just change the date or time in clock/calendar program. I have the clock/calendar program set to display a digital time, so to speak, and to show a calendar when it’s icon is clicked. When I made the value of TZ “global” by setting and exporting it from “.profile”,then logged in again, the icon of the clock/calendar program went blank. I was still able to click on it, but no year, no date, etc., was shown. That’s why I described it as being “clobbered”. Yet the value I set for TZ was valid. That situation seems rather strange to me. I would naturally have expected that either the clock/calendar program would not rely on TZ, or if it does, it would interpret and use the value correctly.

  2. setting TZ using a variety of GNU or POSIX formats ONLY in the Application=>Command property within the individual launcher from the panel. AFAIK, parameters are substituted into that command, and then the command is run. Naturally as you suggested, it only affected Opera, not the clock/calendar program. Yet, no matter what format I used, and quadruple checked for accuracy, Opera did not use it properly. I had hoped that if Opera did not interpret a valid compound format, which specifies the differences between standard time and daylight and when to apply them, it would at least properly use an offset from UTC. So I put together an executable sequence of commands using “back ticks”. That determined the hour WRT UTC, and the hour in the current time zone, then calculated the difference, and effectively plugged it into an expression such as TZ=“UTC-x” prepended to the Opera command to be run. From the result within Opera it was evident that was executing properly, but if the time was correct, the date was not.

I’d naturally considered:

A) a possible problem with the system time.
B) a possible problem in my User config files, etc.
C) I’ve had things I’ve wanted to adjust with Opera’s start up in the past, where people have suggested either X-Windows related options, or options that are in some way effectively supported by the Chromium package. That is why I wondered how any code relating to the Chromium package might interpret, or “depend on” the value of TZ.
D) possible “bugs” in Opera or something related to it.
E) etc.

More recently, I finally installed Leap 15.2. I seemingly found an outright bug in Opera. If there’s one…

Within Leap 15.2 I tried to run Opera as root. I got a message indicating that root was not allowed to run Opera without a particular command line option. When I supplied that command line option, Opera then complained that the option was unsupported. Ooops!

I created a Guest User account and ran Opera from it. After I visited various websites, I displayed the history. The time, month, and year were correct, but the links I had just visited, which were labeled as being from today, had yesterday’s date of the month, and yesterday’s day of the week shown. In the same environment, Chrome shows those things correctly. I’ve also tried other browsers that show dates and times for history, and Opera seems to be the only one with the problem.

Given what you mentioned about Falkon, I made a point of trying that. Unfortunately, even though it has a column labeled “Date” in the history, for what I visited today, even after widening the column, it only shows the time. Since it does show the date for older links, I’ll be very interested to see what it shows tomorrow.

However esoteric the issue might be, when in the same environment, Opera uses the time base incorrectly, but multiple other browsers use it correctly, it seems to be an issue with Opera.

I just opened “opera”.

Then I immediately checked history.

At the top of the history page, it said:

Today - Sunday, July 26, 2020

So it is off by 1 day.

Why did I not see that on previous checks? I don’t really know, except that this morning I decided to use Wayland instead of X11 for the graphics. Perhaps Opera doesn’t like Wayland.

So are you using Wayland?

If you are not sure, then try:


in a konsole session.

The output was x11.

Interesting. So it isn’t Wayland.

There’s another thing I notice. When I select “History” from the main menu, there is a sub-menu with “History” as the first item, and then another “history” lower under “recently closed”. And I think I was previously looking at the lower “history”. But now, under Wayland, I can’t access that – it disappears before I can click. So instead, I’m looking at the top “History”. And perhaps I missed the problem by not doing it that way before.

In any case, I think I have confirmed that this is an opera bug of some kind.