Should we ignore some API properties like "asString" and "eta"?

[Erlite]

Per the title, I wonder if we should just ignore some of the properties returned by the API. They seem to be generated by the data returned from the real Warframe API, and some of it really isn't needed as we can make it ourselves in the wrapper. This would reduce the clutter inside model classes like this:

[JsonProperty("eta")]
public string TimeRemainingString { get; private set; }

[JsonProperty("startString")]
public string TimeSinceStartString { get; private set; }

Thoughts?

[Erlite]

Decided to go through and delete these properties, they're really just adding clutter to the models.

[TobiTenno]

eta is an prediction for end time based on current running time, so i'd include those, and asString are essentially the .toString() outputs for several of them to give a simple format... I'd hardly call that "clutter"

[Erlite]

By clutter I meant things that could easily be worked as an auto implemented property, such as the asString property. However, I didn't know about the fact that eta was a prediction so I will add it back. I might override ToString() to replicate the asString property.

[Erlite]

I'll work on overriding ToString() later.

[VaslD]

Should ETA (property) be calculated if we knew the exact ETA (as DateTime stored in another property, e.g. Activation, Expiry, etc.)? Time is always-running in real time so it doesn't make sense to store countdown as fixed Strings.

[VaslD]

For example on Sorties, both Activation and Expiry exist as properties returning DateTime; therefore, both "time since Sortie started" and "time until Sortie ends" can be calculated from DateTime.Now.

Also I'd try not to use the phrase "ETA" when both start and end times are known, because the A in ETA can mean both (arrival vs. accomplish).

[Erlite]

I just stored them since the API did, but yeah we could just calculate that in a property.