GNOME Bugzilla – Bug 568797
on 64 bit machines the date is wrong
Last modified: 2009-09-29 00:33:03 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.
*** Bug 564586 has been marked as a duplicate of this bug. ***
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.
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.
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
*** Bug 571568 has been marked as a duplicate of this bug. ***
this is fixed in TRUNK, together with edit activity revamp
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.
any news Matthew - is it working? :)
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?
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 :)
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
You might want to try updating if possible. We're currently on 2.27.1.
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
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?
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?
Created attachment 133533 [details] hamster initially
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)
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)
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
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...
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
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.
*** Bug 589993 has been marked as a duplicate of this bug. ***
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.