DOM Extender: Json dates are evil

[JTaylor]

Assuming you have the latest, those return a Type of "UTC", don't they?    Also, you should be able to return a YmdHms format if desired.

Jim

[stanl]

Assuming you have the latest, those return a Type of "UTC", don't they?    Also, you should be able to return a YmdHms format if desired.

Jim

Yes, but if you check the Newtonsoft thread I just uploaded, dates are converted w/out .000Z.  This goes back to my original statement that you should just return everything as Text and let the user decide how to deal with it.

[JTaylor]

Not sure I understand.   I do return the dates as they are unless you explicitly request the YmdHms format.   

Are you getting .000Z tacked onto something?   I can convert dates that don't have a Z on the end if that is what you mean and if needed.   That is why I asked about them earlier in this thread but no one responded. 

The examples you posted have the Z so that is creating a bit of confusion in my mind.   Plus it sounds like you are getting back dates from my extender in some odd form that NewtonSoft doesn't.   If you mean they are just chopping off the milliseconds I can make that an option as well, if you think that would be helpful to people.   I am just trying to make things as easy for people as I can.



Jim

[td]

Stan's Newtonsoft script is preprocessing the data values through a database assembly, so an examination of the intermediate data that the Newtonssoft assembly is converting to JSON text seems warranted. Also, it is not clear what the rationale is for making Newtonsoft the arbitrator of some JSON conversion standard. That is not to say there isn't a rationale but just that there should be some justification.

[JTaylor]

i just like to help       As noted, one can get the raw value or an YmdHms value if the raw text meets the two stated formats (can account for more if requested).   Apart from that I will let everyone else ponder the bigger questions.

Jim

[stanl]

Stan's Newtonsoft script is preprocessing the data values through a database assembly, so an examination of the intermediate data that the Newtonssoft assembly is converting to JSON text seems warranted. Also, it is not clear what the rationale is for making Newtonsoft the arbitrator of some JSON conversion standard. That is not to say there isn't a rationale but just that there should be some justification.

Au contraire. Tony already chipped in about standards. I throw stuff like the Newtonsoft script because I now know it works. I have also thrown out examples of different date interpretation.

• Newtonsoft works with WB [it didn't for me in 2013, but that was my problem]
• Json pretty much ends up everywhere no; for me personally- in an API [work-related, cannot share]
• I could use CLR strings to create my own Json from anything
• Json 'object' typing - like the way the dates came in as milli-seconds - is it's own topic.

I expect a STFU from someone on these threads pretty soon

[ChuckC]

https://www.newtonsoft.com/json/help/html/T_Newtonsoft_Json_Converters_IsoDateTimeConverter.htm

Newtonsoft JSON has a built-in date & time converter class, IsoDateTimeConverter, using a time format string of "yyyy-MM-ddTHH:mm:ssZ".  However, usage of the converter is discretionary.  And, it's possible to derive new converter classes from it that set a different format string in their c'tor method.

What you have is still ISO 8601 compliant, even though the precision is truncated to whole seconds instead of going out to some decimal fractional amount.  If the trailing "Z" is missing, then the time is assumed to have an unknown time zone.  If the "Z" has been replaced with a
"+" or "-" followed by "HH:mm", then it's a local time in a time zone represented by an offset from GMT.

What is going to be key when dealing with dates in JSON is that there simply is no one single unified representation of a date & time value as a string for purposes of interchange via JSON.  As a result of this, there has to be either a contract where the provider & consumer agree on a format, or the consumer simply has to be aware of all possible representations and must be capable of handling them all.  You might be able to do some pattern matching with a RegEx that would permit some kind of heuristic for automatically choosing a date & time "decoder", but it won't be inexpensive in terms of performance and it won't be 100% reliable.

caveat emptor, YMMV, and all other suitably applicable disclaimers, etc...

[JTaylor]

This gives me some ideas.   I will probably just add a function where one can submit a UTC or time_t  value for conversion to YmdHms.  That way if they are retrieving values for other time zones they can tweak to align with GMT and get it in local time.  Seems the most flexible and keeps me from "trying" to account for all possibilities.

Thanks.

Jim

[td]

Au contraire. Tony already chipped in about standards. I throw stuff like the Newtonsoft script because I now know it works. I have also thrown out examples of different date interpretation.

• Newtonsoft works with WB [it didn't for me in 2013, but that was my problem]
• Json pretty much ends up everywhere no; for me personally- in an API [work-related, cannot share]
• I could use CLR strings to create my own Json from anything
• Json 'object' typing - like the way the dates came in as milli-seconds - is it's own topic.

I expect a STFU from someone on these threads pretty soon

I can make no sense of your response.  I will just assume you took my very brief analysis to mean something other than what was intended and move on.

[ChuckC]

When it comes to writing code that deals with date & time stamps, I always use UTC time.  It's a no-brainer to apply your local offset to that, and anybody with auto-correcting eyes can condition themselves quickly to mentally converting UTC to local time when looking at log file records and JSON content.

If anybody wants local time presented, they are welcome to convert the DATETIME or time_t values into local times, but any API that I develop explicitly requires UTC times.