You are using an old version of the community app please update to the
latest version.

On Mon, 4 May 2020, 15:05 Airsay Longcon, <[email protected]> wrote:

> Talking about dates, is there any reason why Transaction date (on say a
> Recurring Deposit or Fixed Deposit account) would display null whereas on
> the DB there's a valid date?
>
> Sent from my iPhone
>
> On 4 May 2020, at 08:17, Saransh Sharma <[email protected]> wrote:
>
> 
> Making Standard formatting is the key,
>  Though at the client end we can always display the data however we want.
> It's not going to be a problem at all.
>
>
>
> On Mon, May 4, 2020 at 9:04 AM James Dailey <[email protected]>
> wrote:
>
>> @Michael Vorburger <[email protected]>
>>
>> +1 for your change.
>> Having dealt with date issues in other banking applications, I have come
>> to appreciate the ISO-8601 format.  If only everyone used the same date
>> format is a common lament.
>>
>> I certainly hope no Mifos apps are using the US date standard.  But, if
>> they are, we should certainly modify them, rather than maintain a
>> non-standard output in the APIs.  my 2 cents.
>>
>>
>>
>>
>> On Sun, May 3, 2020 at 4:04 PM Michael Vorburger <[email protected]>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> If you have a particular interest in the fascinating topic of how to
>>> represent dates in JSON responses of REST APIs such as Fineract's, and
>>> therefore have opinions about the code change proposed in
>>> https://github.com/apache/fineract/pull/816 which modifies the format
>>> in which certain dates are returned by the API in an incompatible way, then
>>> please read https://jira.apache.org/jira/browse/FINERACT-926 for full
>>> background, and comment either directly in that JIRA, or on this thread.
>>>
>>> The short version is that I'm proposing that certain date fields in
>>> Fineract's JSON API (those that internally come from java.util.Date
>>> instances, only) be formatted in ISO-8601 format e.g.
>>> "2011-12-03T10:15:30Z" instead of as e.g. "May 3, 2020 10:51:19 PM", as
>>> they are currently. If this could break any of your clients interpreting
>>> such Date fields, please shout now.
>>>
>>> NB that this this will NOT at all affect other date fields, such as
>>> those currently already formatted as e.g. "[2020, 05, 04]" (which
>>> internally come from org.joda.time.LocalDate instances).
>>>
>>> Tx,
>>> M.
>>> _______________________
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>
>
> --
>
> Saransh Sharma
> *Research Partner*
> *Muellner Internet Pvt Ltd *
>
>
> ----------------------------------------------------------------------------------------------
>
> The idea of separation of me and you is amazing.
>
> ----------------------------------------------------------------------------------------------
> *Company Website <https://www.muellners.com/>       **Company Linkedin
> <https://www.linkedin.com/company/muellners>            *Company Facebook
> <https://www.facebook.com/muellners>
>
> This mail is governed by Muellner®  Internet Private Limited's IT policy.
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by e-mail.
>
>

Reply via email to