Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Wed 6 Jan 2021

REST plus RPC: the right data in the right format, and no more



Tue 5 Jan 2021

REST plus RPC: Do the demo backward



Tue 5 Jan 2021

Exciton Boost 4.6.0 and development assistance


January, 2021
SMTWTFS
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

Search the weblog





























Genii Weblog

Exciton Boost and those pesky Date/Time values

Mon 7 Dec 2020, 04:47 PM



by Ben Langhinrichs
Inline JPEG image
 
 
On Friday, Heiko Voight wrote a post called domino-db, proton and Date/Time values. It makes interesting reading, but the gist of it is that domino-db can be mighty persnickity about dates, and not very respectful of time zones. As an example, Heiko pointed out the two dates below. The invalid one was created using a standard JavaScript function that happens to return milliseconds (3 decimal places) rather than hundredths (two decimal places). Rather than either ignore the extra precision or round it off (worthy of debate which is better), Proton simply chokes on it.
 
'2013-03-01T14:09:01.009Z' // Invalid (too precise)
'2013-03-01T14:09:01.01Z' // Valid
 
 
As it typical with domino-db and Proton, this doesn't just return that it is invalid, it pukes all over the screen. (See above.) Even worse in its own way, the time zone information included in the date was ignored, thus interpreting every date as if it were GMT (nice for Gab and Tim, but not many of the rest of us).
 
Out of curiosity, I checked to see what Exciton Boost 4.5.3 did with these dates. We use a date conversion function that is a bit more flexible. It works properly with any of the following:
 
2013-03-01T14:09:01.009Z
2013-03-01T14:09:01.01Z
2013-03-01T14:09:01.0Z
2013-03-01T14:09:01Z
2013-03T14:09:01.009Z
20130301T14:09:01.009Z
2013-03-01T140901.009Z
20130301T140901.009Z
2013-03-01T14:09:01.009-0400
2013-03-01T14:09:01.009-04
2013-03-01T14:09:01.009-0430
2013-03-01
20130301
 
and quite a few other variations, as it happens, including variants such as:
 
Mon,  7 Dec 2020 15:06:31 -0500
Today
Now
@Adjust(@Today; -1; 0; 0; 0; 0; 0);
 
The key concept is that we should be liberal in what we receive and conservative is what we send. Plus, we shouldn't puke all over. If we do manage to give a date format that is not accepted, such as
 
Mom's birthday
 
we are really okay with a simple invalid request mentioning that the date could not be interpreted. (No, mom, we aren't adding that in 4.5.4.)

Copyright 2020 Genii Software Ltd.

What has been said:

No documents found

Have your say:

Name *:
E-mail:
e-mail addresses will not be displayed on this site
Comment *:


<HTML is not allowed>
Linking: Add links as {{http://xxx|title}}, and they will be activated once approved
Blocked? Unable to post a comment? Please read this for a possible explanation...