View Issue Details

IDProjectCategoryView StatusLast Update
0000583Main CAcert Websiteweb of trustpublic2013-01-17 23:58
ReporterDaniel Black Assigned To 
Status closedResolutionduplicate 
Fixed in Version2013 Q1 
Summary0000583: "Assure Somebody" allows future assurance dates
DescriptionThe date on the "Assure somebody" entry form allows future dates to be entered. There is also no indication of the date format. I'd assumed YYYY-MM-DD.

Due to an off by one (month) error on behalf of this user the following assurance IDs appear in 2008-08-24 instead of 2008-07-24

92082,92083,92084,92085,92086 ,92087 ,92088,92089,92093 ,92104,92105,92147
TagsNo tags attached.
Reviewed by
Test Instructions


related to 0000870 closed Main CAcert Website My Details - My Points show bugus time stamp 
related to 0000801 closed Main CAcert Website Date of assurance should be in user's timezone 
related to 0000622 closed WOT - Assure Someone - date is not checked 
related to 0000618 closedSourcerer date of birth - absolutelly no sanity checks 
related to 0000601 closed Main CAcert Website date of birth format in german WoT/TTP forms 
related to 0001137 closedBenBE Main CAcert Website Record the CCA acception for entering an assurance 
related to 0000931 closed Main CAcert Website Date of assurance in future don't throw any exception 



2008-07-26 08:41

reporter   ~0001119

The date field is in fact free text. The real timestamp on the DB row is the official date of assurance (which is not displayed but can be accessible by support)


2008-08-25 23:58

updater   ~0001149

The comment of this field states: Only fill this in if you assured the person on a different day - means enter a date different then the actual date.
possible solutions: insert UTC times if field is empty.
and check field content if not empty against actual UTC

Werner Dworak

2013-01-10 17:29

updater   ~0003636

The initial idea was to allow kind of date entries in free text for special cases.

But finally there is a certain known date when the assurance took place, and this is written to the CAP form. So we can safely demand as an usual format YYY-MM-DD. Then we can check for a valid date not more than 24 hours in the future (to allow for differences in time zones) and not more than maybe 5 years in the past.


2013-01-17 23:58

updater   ~0003697

the date check is included in bug

Issue History

Date Modified Username Field Change
2008-07-26 07:54 Daniel Black New Issue
2008-07-26 08:41 homer Note Added: 0001119
2008-08-25 23:58 Uli60 Note Added: 0001149
2012-05-28 10:16 INOPIAE Relationship added related to 0000870
2012-12-27 05:41 Werner Dworak Relationship added related to 0000931
2013-01-10 17:29 Werner Dworak Note Added: 0003636
2013-01-10 17:29 Werner Dworak Status new => needs work
2013-01-10 17:44 Werner Dworak Relationship added related to 0000801
2013-01-10 17:48 Werner Dworak Relationship added related to 0000622
2013-01-10 17:49 Werner Dworak Relationship added related to 0000618
2013-01-10 17:50 Werner Dworak Relationship added related to 0000601
2013-01-17 23:57 INOPIAE Relationship added related to 0001137
2013-01-17 23:58 INOPIAE Note Added: 0003697
2013-01-17 23:58 INOPIAE Status needs work => closed
2013-01-17 23:58 INOPIAE Resolution open => duplicate
2013-01-17 23:58 INOPIAE Fixed in Version => 2013 Q1