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 516787 - Key expiration date shows incorrect value when its set above y2k38
Key expiration date shows incorrect value when its set above y2k38
Status: RESOLVED FIXED
Product: seahorse
Classification: Applications
Component: general
2.20.x
Other Linux
: Normal minor
: 2.22.0
Assigned To: Seahorse Maintainer
Seahorse Maintainer
: 592532 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-02-16 02:15 UTC by Josselin Mouette
Modified: 2009-08-21 02:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Description Josselin Mouette 2008-02-16 02:15:32 UTC 
[ forwarded from http://bugs.debian.org/463690 by Gonzalo Bermúdez ]

My key has its expiration date set to 2080-31-12. This is correctly 
displayed by gpg, and on the calendar icon next to "Expires:" on the 
key's properties on Seahorse, but as 1944-11-25 on the field, in the 
same window.
Comment 1 Adam Schreiber 2008-02-16 02:33:26 UTC 
I'm not sure if this is a bug that seahorse can fix by itself.  We get a ulong seconds past the epoch from gpgme which returns the correct number.  However, all of the gtk date and time functions take a 32 bit number or whatever time_t is on your system (32 or 64 bits)[1].  Therefore if your system was 64 bit hypothetically everything would just work (tm) if we switched to non-deprecated date and time functions.

[1] http://library.gnome.org/devel/glib/unstable/glib-Date-and-Time-Functions.html#g-date-set-time
Comment 2 Stef Walter 2008-08-06 02:10:31 UTC 
Adam is correct. We'd just need to verify that this works properly on 64 bit.

GPGME returns a 'long int' as the expiry date, so I don't think this can ever be made to work correctly on 32 bit systems as long as we stick with GPGME.

The deprecated g_date_set_time usage in seahorse is also gone.
Comment 3 Tommi Asiala 2008-12-05 17:01:52 UTC 
Verified on 64 bit platform and 2.24.1:
1. create a new with gpg --gen-key
2. set the expiration date to +70y
3. seahorse shows the key expiration 2078-11-18

Please close this bug.
Comment 4 Adam Schreiber 2009-08-21 02:06:33 UTC 
*** Bug 592532 has been marked as a duplicate of this bug. ***