View Issue Details

IDProjectCategoryView StatusLast Update
0004521Talerotherpublic2016-11-20 03:26
ReporterFlorian DoldAssigned ToMarcello Stanisci 
PrioritynormalSeveritytextReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.0 
Target Version0.2Fixed in Version0.2 
Summary0004521: inconsistent terminology: edate vs expiration date vs refund deadline
Descriptionedate seems to stand for "expiration date", but in the code/config we use it for the wire_deadline. This is confusing, we should agree on a consistent terminology.
TagsNo tags attached.

Relationships

related to 0004645 closedChristian Grothoff Refactor of Taler API's documentation 

Activities

Florian Dold

2016-05-23 13:55

manager   ~0010706

To make things worse, the contract also has an "expiry" field, which is the expiry date of the contract.

Marcello Stanisci

2016-05-23 20:34

manager   ~0010712

Last edited: 2016-05-23 20:36

View 2 revisions

I'd suggest the 'exp_' (or 'expiration_') prefix for those fields which indicate an expiration, and 'date_' for those who indicates a precise point in the time when something should happen; so the naming becomes:

- exp_contract (in place of "expiry")
- exp_refund (in place of "refund_deadline")
- date_wire (in place of "edate"/"wire_deadline")

Florian Dold

2016-05-23 20:41

manager   ~0010713

I don't see how this makes sense. Except for EDATE in the configuration (which is a relative time), these are all deadlines (absolute time).

By the way, looking at the source code, edate stands for execution data and not expiration date.

We should just find a better name for "edate" in the config, and have a less ambiguous name for the "expiration" field of the contract.

Christian Grothoff

2016-05-23 23:23

manager   ~0010715

I'm generally for spelling things out long, rather than having obscure and possibly misunderstood short names.

Marcello Stanisci

2016-05-23 23:31

manager   ~0010716

Last edited: 2016-05-24 00:57

View 2 revisions

"edate" becomes absolute when it is a field in the deposit permission [1]. For consistency/readability, we should use the same name for config values that are (or originate) a JSON field. Alternatively, if some relative time in configuration originates a JSON field x, that value may be called x_delta. In practice, the config value 'date_wire_delta' originates 'date_wire' in the deposit permission's JSON.

Anyway, the meaning of 'expiration_x = y' is "do x *not later than* y" and for 'date_x = y' is "do x *at time* y"; regardless of the fact that their value originated from an absolute or relative time.

[1] http://api.taler.net/api-exchange.html#post--deposit

Christian Grothoff

2016-05-26 14:51

manager   ~0010766

expiration (in contract) should become pay_deadline (last chance to pay, offer ends).

edate should become wire_transfer_deadline for absolute, and wire_transfer_delay for configuration (relative).

Christian Grothoff

2016-05-26 15:25

manager   ~0010767

edate change done (in exchange, merchant, api and deployment).

Christian Grothoff

2016-05-26 15:50

manager   ~0010769

I cannot really find 'expiration' in the merchant's source code, which is odd. Maybe we currently do not check it? (but should...?).

Changing 'expiration' to 'pay_deadline' right now seems to be simply a very small change in the API. Marcello, could you please do this (and add a check for expired contracts on /pay in the backend?)

Marcello Stanisci

2016-10-20 14:27

manager   ~0011362

fixed in merchant 2854239

Issue History

Date Modified Username Field Change
2016-05-23 13:53 Florian Dold New Issue
2016-05-23 13:55 Florian Dold Note Added: 0010706
2016-05-23 20:34 Marcello Stanisci Note Added: 0010712
2016-05-23 20:36 Marcello Stanisci Note Edited: 0010712 View Revisions
2016-05-23 20:41 Florian Dold Note Added: 0010713
2016-05-23 23:23 Christian Grothoff Note Added: 0010715
2016-05-23 23:23 Christian Grothoff Severity minor => text
2016-05-23 23:23 Christian Grothoff Status new => acknowledged
2016-05-23 23:23 Christian Grothoff Product Version => 0.0
2016-05-23 23:23 Christian Grothoff Target Version => 0.1
2016-05-23 23:31 Marcello Stanisci Note Added: 0010716
2016-05-24 00:57 Marcello Stanisci Note Edited: 0010716 View Revisions
2016-05-24 20:52 Christian Grothoff Assigned To => Christian Grothoff
2016-05-24 20:52 Christian Grothoff Status acknowledged => assigned
2016-05-26 14:51 Christian Grothoff Note Added: 0010766
2016-05-26 15:25 Christian Grothoff Note Added: 0010767
2016-05-26 15:50 Christian Grothoff Note Added: 0010769
2016-05-26 15:50 Christian Grothoff Assigned To Christian Grothoff => Marcello Stanisci
2016-09-07 16:58 Marcello Stanisci Relationship added related to 0004645
2016-09-27 22:29 Christian Grothoff Target Version 0.1 => 0.2
2016-10-20 14:27 Marcello Stanisci Note Added: 0011362
2016-10-20 14:27 Marcello Stanisci Status assigned => resolved
2016-10-20 14:27 Marcello Stanisci Resolution open => fixed
2016-11-15 16:03 Christian Grothoff Fixed in Version => 0.2
2016-11-20 03:26 Christian Grothoff Status resolved => closed