Date format in JSON - OpenEdge Development - Forum

All Replies

Posted by Jean-Christophe Cardot on 31-Jan-2019 10:41

Hi!

There is one and only one date format in the JSON format: yyyy-mm-dd.

Both the producer and the consumer must adapt themselves to this format.

Can you please tell why you would need something else?

Posted by bronco on 31-Jan-2019 10:45

JSON itself has no standard format for dates, Javascript does however and the format is yyyy-mm-dd. So OpenEdge serializes to the standard and to be honest, not giving an option there is a good idea (that's where standards are for). So AFAIK, you either play by the rules (yyyy-mm-dd), or make it a CHARACTER. It's one or the other.

Posted by frank.meulblok on 31-Jan-2019 11:04

[quote user="Jean-Christophe Cardot"]There is one and only one date format in the JSON format: yyyy-mm-dd.[/quote]

This is not true. The official JSON standards (see https://www.json.org/) do not specify any standard format for date/datetime related data.

Most people go with yyyy-mm-dd because that follows the ISO 8601 standards for date formatting because filling the gap in the JSON standards with another, well documented and pre-existing standard just makes a lot of sense. But that's decided by platform and implementation of the JSON provider/consumer, and not something that's guaranteed at all.

Posted by Richard.Kelters on 31-Jan-2019 11:24

In JSON it is formatted like that but if you map the value to a date field in OpenEdge it will be converted for you to the correct date I believe.

Posted by Jean-Christophe Cardot on 31-Jan-2019 11:44

thanks Frank

Posted by Torben on 31-Jan-2019 14:16

Add your own datatypes. Fx

CLASS Json.MyJson INHERITS JsonObject:
   METHOD PUBLIC LOGICAL AddMyDate( INPUT propertyName AS CHARACTER, INPUT dValue AS DATE):
      DEFINE VARIABLE cDate AS CHARACTER NO-UNDO.
      cDate = STRING(dValue, "99/99/9999"). // Your date formatting to string.
      RETURN THIS-OBJECT:Add(propertyName, cDate).
   END METHOD.
   METHOD PUBLIC DATE GetMyDate( INPUT propertyName AS CHARACTER):
      DEFINE VARIABLE cDate AS CHARACTER NO-UNDO.
      cDate = THIS-OBJECT:GetCharacter(propertyName).
      RETURN DATE(cDate). // YOur conversion from string to date
   END METHOD.
END CLASS.

Posted by Peter Judge on 31-Jan-2019 14:48

The OE JSON objects will convert to and from ABL primitives (date, datetime, datetime-tz) from JSON strings and nulls. The strings must use (as noted elsewhere) be formatted per the ISOL 8601 standard.

You can use the GetType() method to check what type the JSON is, but the only way to convert to an ABL date/time/tz is to do the Get*() with no-error or a catch block. There are no TryGet()or GetAblType() methods on the built-in JSON objects.

The example below shows some examples.

using Progress.Json.ObjectModel.JsonObject.

def var oj as JsonObject.

def var lc as longchar.

def var d1 as date.

def var d2 as date.

def var dt1 as datetime.

def var dt2 as datetime-tz.

oj = new JsonObject().

oj:add('date', today).

oj:add('notadate', 'abcdefg').

oj:add('datetime', datetime(today, mtime)).

oj:add('datetime-tz', datetime-tz(now)).

oj:write(input-output lc).

d1 = oj:getdate('date').

//d2 = oj:getdate('notadate').

dt1 = oj:getdatetime('datetime').

dt2 = oj:getdatetimetz('datetime-tz').

message

string(lc) skip(2)

oj:getType('date') skip //Progress.Json.ObjectModel.JsonDataType:STRING

oj:getType('notadate') skip //Progress.Json.ObjectModel.JsonDataType:STRING

d1 skip

oj:getType('datetime') skip

dt1 skip

oj:getType('datetime-tz') skip

dt2

view-as alert-box.

If you try to read a date from a character field that’s not date/time/tx-formatted you get something like

---------------------------

Error (Press HELP to view stack trace)

---------------------------

** Invalid date input. (85)

---------------------------

OK Help

---------------------------

Posted by jquerijero on 31-Jan-2019 15:38

Is there an equivalent to C# TryParse to avoid using too many CATCH phrase when GetSomeType() fails?

Posted by Peter Judge on 31-Jan-2019 16:34

Sadly not.

This thread is closed