After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568797 - on 64 bit machines the date is wrong
on 64 bit machines the date is wrong
Status: RESOLVED OBSOLETE
Product: hamster-applet
Classification: Deprecated
Component: general
2.26.x
Other Linux
: Normal normal
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
: 564586 571568 589993 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-23 02:08 UTC by Anand Kumria
Modified: 2009-09-29 00:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hamster initially (24.38 KB, image/png)
2009-04-29 01:07 UTC, Anand Kumria
Details
hamster after switch to a task, and attempting to edit it (444.45 KB, image/png)
2009-04-29 01:08 UTC, Anand Kumria
Details

Description Anand Kumria 2009-01-23 02:08:30 UTC
Hi,

when modifying a tasks particular details, or attempting to add an earlier activity - on 64 bit machines the date is wrong.

e.g. the current date is 2009-01-23 but hamster will display 02/10/66 when you attempt to update the activity.
Comment 1 Toms Bauģis 2009-01-23 08:53:02 UTC
*** Bug 564586 has been marked as a duplicate of this bug. ***
Comment 2 Matthew Hurne 2009-01-26 18:01:08 UTC
I am seeing this problem as well, when adding an earlier activity and when editing an earlier activity that already exists.  Another issue I'm having, though possibly unrelated, is that saving an edit to an earlier activity seems to cause that activity to disappear.  But maybe its still there, just with the date changed.
Comment 3 Anand Kumria 2009-01-27 04:51:12 UTC
I transferred the hamster.db from a 32 bit machine to a 64 bit machine and things are now mostly working.

The issue that Matthew mentionds (save an edit to an earlier activity and it disappears) also occurs to me as well.
Comment 4 Toms Bauģis 2009-01-29 17:50:15 UTC
the time is set in line 62 of add_custom_fact.py

self.get_widget('start_date').set_time(int(time.mktime(fact_date.timetuple())))

Maybe somebody could tell me what is wrong there?

fact_date is standard date-time.
the widget start_date is GnomeDateEdit - which, i don't know - is it obsolete or what's the problem? 

All in all, there is no analogue in pygtk, so, if this one is broken, then we need to create one ourselves. Found a chat[1] about a guy who was doing that back in 2005

[1] http://www.mail-archive.com/pygtk@daa.com.au/msg12190.html
Comment 5 Toms Bauģis 2009-02-13 23:39:26 UTC
*** Bug 571568 has been marked as a duplicate of this bug. ***
Comment 6 Toms Bauģis 2009-02-28 00:13:33 UTC
this is fixed in TRUNK, together with edit activity revamp
Comment 7 Matthew Hurne 2009-02-28 01:52:10 UTC
Thank you God.  Or should I say, Toms!  I've really been missing my hamster.  :-)  Can't wait to get it back up-and-running.
Comment 8 Toms Bauģis 2009-04-12 20:25:09 UTC
any news Matthew - is it working? :)
Comment 9 Ashton Kemerling 2009-04-23 04:30:00 UTC
I'll setup a virtual machine here this weekend and test it out for you. Did you just fix the time, or did you also get the editing bug Matthew mentioned?
Comment 10 Toms Bauģis 2009-04-23 07:53:24 UTC
the whole approach has been changed and date widget dumped in favor of house made one. I was running 64 bit machine for a while myself and could verify that it works. I did not verify, however, that the previous one did not work (this bug had skipped out of my mind).

So, hum, i say we close this bug!


Thanks for reminding Ashton, and sorry for the mess, hehe :)
Comment 11 Anand Kumria 2009-04-23 12:45:39 UTC
Even though the entire approach has changed this bug crops up *still* on hamster-applet 2.26.1

Particularly noticable when editing a task.

Or using 'add an earlier task'.

Basically so long as you switch between things, that is okay.

But as soon as you edit - the date box is populated with a garbage date, sometimes in the future, sometimes in the past.

Do you want screenshots, examples, traces, the sqllite3 db?

Thanks,
Anand
Comment 12 Ashton Kemerling 2009-04-23 13:14:38 UTC
You might want to try updating if possible. We're currently on 2.27.1.
Comment 13 Toms Bauģis 2009-04-23 13:22:13 UTC
Ah, sorry, things changed in the HEAD (2.27+).

Of course, you are right, we should solve it in 2.26.

I'm not sure what i can do, basically the salt of problem for this bug is in add_custom_fact.py line 62 [1]:

self.get_widget('start_date').set_time(int(time.mktime(fact_date.timetuple())))

We can split it up in following steps:

import datetime, time
today = datetime.date.today()
epoch_seconds = time.mktime(today.timetuple())
print epoch_seconds
#self.get_widget('start_date').set_time(epoch_seconds)

The datetime widget expects time to get in seconds since epoch, and something goes wrong here. 
Is the epoch calculated the wrong way, or is the widget expecting something else, and what does it all have to do with 64 bit machines?

Hypothesizing will take way too much time
So if you feel a bit adventurous, rolling up the sleeves and trying to pop this one would be most appreciated!

You can try to run the 4 lines in python and paste output here, so we can start deducing :)


[1] http://git.gnome.org/cgit/hamster-applet/tree/hamster/add_custom_fact.py?h=gnome-2-26#n62
Comment 14 Anand Kumria 2009-04-24 12:15:28 UTC
anand@saltatrix:~$ lsb_release -rd
Description:	Ubuntu 9.04
Release:	9.04

anand@saltatrix:~$ uname -a
Linux saltatrix 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

anand@saltatrix:~$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime, time
>>> today = datetime.date.today()
>>> epoch_seconds = time.mktime(today.timetuple())
>>> print epoch_seconds
1240527600.0
>>> 

anand@saltatrix:~$ date +%s
1240575116

I also tested this on a 32-bit system and the same epoch_seconds is printed out too (with the period).

Anything further I can help with?
Comment 15 Patryk Zawadzki 2009-04-28 11:10:45 UTC
Could you please attach a screenshot, output of "locale" and the output of "date +%x"?

Can you confirm it works properly on a 32-bit system with the same libgnomeui version, same pygtk version and same locale settings?
Comment 16 Anand Kumria 2009-04-29 01:07:36 UTC
Created attachment 133533 [details]
hamster initially
Comment 17 Anand Kumria 2009-04-29 01:08:57 UTC
Created attachment 133534 [details]
hamster after switch to a task, and attempting to edit it

Notice the date is wrong (this was done about 10 mins ago) (2009-04-29 02:08)
Comment 18 Anand Kumria 2009-04-29 01:10:10 UTC
anand@saltatrix:~$ uname -a
Linux saltatrix 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

anand@saltatrix:~$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

anand@saltatrix:~$ date +%x
29/04/09

I can confirm that using the same locale on a 32bit machine, hamster-applet works perfectly fine. Both the 32 and 64 bit machine are running Ubuntu Jaunty (9.04)
Comment 19 Anand Kumria 2009-04-29 01:17:58 UTC
Hmm, decided to look into this:

In /usr/share/pyshared/hamster/add_custom_fact.py we have, line 71:


        if fact_id:
            fact = storage.get_fact(fact_id)
            print fact
            self.get_widget('start_date').set_time(int(time.mktime(fact["start_time"].timetuple())))

Should that be fact["start_time"] or fact["start_date"]?

Anand
Comment 20 Andrew W. Nosenko 2009-04-29 08:25:24 UTC
Sorry, I know absolutelly nothing about python types, and therefore may be wrong, but casting to 'int' in 

  set_time(int(time.mktime(fact["start_time"].timetuple())))
           ^^^

seems danger from C point of view...  Just because time_t is 64 bits wide while int only 32.

Sorry for noise...
Comment 21 daniele 2009-04-30 18:47:47 UTC
I just add that adding previous task from applet window (the one that appear clicking on applet) work correctly, while adding task from report does not work.
so
self.get_widget('start_date').set_time(int(time.mktime(fact_date.timetuple())))
too dont work
...
could someone write a short python code that show window with date widget and
set date via set_time .. a test case, it look like a pygtk problem
Comment 22 Toms Bauģis 2009-07-12 17:30:30 UTC
just a status update: unless somebody comes up with a patch, this bug is a WONTFIX. 
2.27.x branch is circumventing this buy using different widget than the deprecated datetime picker.
Comment 23 Mac Ryan 2009-08-10 12:41:37 UTC
*** Bug 589993 has been marked as a duplicate of this bug. ***
Comment 24 Toms Bauģis 2009-09-29 00:33:03 UTC
as i mentioned in comment 22, it has been fixed in devel series and now rolled out in 2.28, thus i'm closing the bug report. 

sorry that i could not do much with this specific bug, in essence it was due to us using a deprecated / forgotten date widget that was not marked as such.