time = 00:00 or resuming across midnight still shows yesterdays date

[Paul Sladen]

Binary package hint: indicator-datetime

Not a creature was stirring, not even a mouse... At midnight (time == 00:00) the applet still shows yesterdays date for one minute until the further tickover to 00:01. Ideally the date should advance at the same time as the time!

...Sadly I was not fast enough to grab a screenshot (global keys are grabbed when the indicator menu is open) but shall try again when I'm still awake at the right time.

[Kalle Valo (kvalo)]

I cheated and set the time manually, and I see this as well. At "12:00 AM" indicator was saying it's Tuesday but at at "12:01 AM" it was saying it's Wednesday. (I'm using 12h clock, but it shouldn't matter here.)

[Jacopo Moronato (jmoronat)]

You could better notice when suspending and, after midnight, resuming.

[calinb (cbrabandt)]

"My" bug, #733766 is listed as "invalid" as it was deemed to be a duplicate of this bug. I don't believe this is the case. My date NEVER updates when using Unity, and it doesn't matter if I use suspend or hibernate.

But I don't feel like arguing about it. I listed sufficient information under my bug filing for devs to arrive at what I feel is a better conclusion. I solved the problem for myself; I simply quit using Unity and went back to Gnome. Problem solved! Ubuntu might have problems when Unity becomes the default desktop manager next release. Good luck! Unity still seems pretty buggy to me.

-Cal

[Paul Sladen (sladen)]

Cal: thank you for reporting that the bug, it took your time, and that is appreciated. Reporting bugs allows them to be documented. Documented bugs allows them to be researched and fixed.

The same requirement to locate, document and fix bugs applies equally, whether you're using GNOME with GNOME2 Panel, GNOME with GNOME3 Shell, GNOME with XFCE, GNOME with Unity (-compiz) shell, GNOME with Unity-2D shell, GNOME with Ubuntu classic desktop, or GNOME with …

Everyday, the same core bugs exist across distributions, and just like them, the same core bugs are also there across across Shells across distributions. The bugs exist, and they just manifest themselves differently depending on the environment. More testers, more diverse codepaths, more shells, more use-cases: these all help to pin-point the bugs that are in there. In the example I gave earlier on the Sounder mailing list, the bug had *always* been there, and wasn't even in, or caused by Unity. Instead, it was the in-depth large-scale testing of Unity that brought it to the front and ensured that a bug finally got the attention it deserved:

  https://lists.ubuntu.com/archives/sounder/2011-April/016120.html (talking about bug #175874)

To makes things more comfortable, I have unduped bug #733766, twiddled the status around to "Needs Info" (it's unclear how to reproduce it at the moment), and *with the status twiddled* I've remarked it as a duplicate of this bug. The original status under a duplicate does not matter in this case, but I appreciate how it could be seen as dismissive. It has not been dismissed, but has proactively been marked as an intimate associate of this bug, which is scheduled to be worked on (admitted, set at Low at the moment since it's a event-based rendering glitch and doesn't appear to cause any data-loss). If you can highlight how this might cause wider issues, we can perhaps both work to bump up the priority.

In the case of bug #733766 (your report), bug #747982 (the other dup) and this bug report: there's clearly a commonality in the logic failure: something that is failing in knowing when to poke dbus-menu with the updated value for the disabled entry date entry in the calendar menu. The various manifestations of "at midnight", or "missed during suspend" or "randomly on other undefined but unclear occasions" (to paraphrase your specific report) are clearly *not isolated* and are ultimately going to get investigated and solved at the same time.

I'm more than happy to further tweak the summary line of this bug report if you can suggest a title that would be more appropriate, the title is there to aid and help /other users and developers/ to find /this bug/ themselves when searching.

Specifically on "back to Gnome": regardless of where a user downloads their GNOME environment from, there *will* be an enforced change in default graphical shell in the short/medium-term. GNOME + GNOME3 Shell is arguably a big jump for people who have not seen it before, and GNOME + Unity is another jump. One might be a shorter jump than the other for any particular group of people depending on their past experiences. Neither new shell option is perfect and both need to...

[calinb (cbrabandt)]

Paul, Thanks for the explanation and changing the status of bug #733766 to "incomplete."

> Everyday, the same core bugs exist across distributions, and just like them, the same core bugs are also there across across Shells > across distributions. The bugs exist, and they just manifest themselves differently depending on the environment.

It sounds like you suspect this is the case here and I understand the reasons for your suspicions. I hope that the symptoms are all caused by the same bug and they are all fixed together.