Date encoding for indices or values?

[Daniel Eisner]

Is there an agreed standard for encoding timetsamps and/or dates as either indices or values? I see that json-stat uses a string-representation for populating the "updated" field. It can be costly to convert dates/times to and from that representation, so not sure if that's the best encoding for the actual bulk data.

[Xavier Badosa]

Sorry for this late reply, Daniel. Could you elaborate?

JSON-stat uses ECMA-262 Date Time String Format for the "updated" property because it's a time standard and allows providers to choose their preferred precision for timestamps.

For time dimensions, that's generally not very useful because most of the time categories refer to time references (usually, natural time periods) instead of timestamps. You can always follow SDMX CL_TIME_FORMAT. Common practices (some are CL_TIME_FORMAT compliant, some aren't): "2016" (year), "20161" / "2016Q1" (quarter), "201601" / "2016M01" (month).

X.

[Daniel Eisner]

Thanks.

You can always follow SDMX CL_TIME_FORMAT. Common practices (some are CL_TIME_FORMAT compliant, some aren't): "2016" (year), "20161" / "2016Q1" (quarter), "201601" / "2016M01" (month).

Sure, I can determine some encoding myself and just do that, but one of the huge advantages of json-stat is all the off-the-shelf library implementations. So, it would be nice if the standard includes a date encoding, which can then be implemented in all the off-the-shelf libraries. That way, I (and others) can use it to pass dates around without having to do any custom coding.

I think we should pick a time encoding standard and state that it is the timestamp-encoding standard used by json-stat. SDMX_CL_TIME_FORMAT seems like a reasonable standard. So does https://temporenc.org/. I’m fine with anything, as long as it is standardized and can therefore be relied upon to be compatible across libraries.

[Xavier Badosa]

On dimension encoding, JSON-stat is agnostic and IMHO it's good to keep it that way so it can be adopted by different providers that have in place different practices. Time is not particularly special in JSON-stat and I think this is also very provider-friendly as many see and treat time as just another dimension and care mainly about the public label and not too much about the internal code (many choose an internal code that can be used as a public label).

That said, of course I believe it would be good to agree on a standardization on common dimensions like time, sex, age... I just don't think that's JSON-stat's job.

X.