Re: validThrough and validUntil

I have no strong opinion about this, but my quick guess ist that validThrough can do the job in most or all cases thanks to the possibility to indicate the exact point in time up to fractions of a second that is included. ISO 8601 puts no limit on the number of digits for indicating fractions of a second, so

    2018-04-05T12:30.31415926536Z

is perfectly valid (comma and decimal dot are valid as a separator, btw).

You can even specify that a credit card expired exactly with the end of the last leap second ("60" is used to denote a leap second in ISO8601):

    2016-12-31T23:59:60

(See https://en.wikipedia.org/wiki/Leap_second for details on leap seconds.)

It's likely that not all systems consuming schema.org support the entire power of ISO8601, but I think this shows that we can likely get away with just validThrough.

Best wishes
Martin
-----------------------------------
martin hepp  http://www.heppnetz.de
mhepp@computer.org          @mfhepp




> On 07 Aug 2018, at 16:04, Thad Guidry <thadguidry@gmail.com> wrote:
> 
> I strongly feel we should keep both.
> 
> The reasoning behind this is that the data could be inclusive or exclusive of a Day if the Time component is not provided.  Governments and business might use either form, and its useful to know if something will cease being valid at the end of a day (validThrough) or at the beginning of a new day or some end time (validUntil).  I deal with this kind of distinction daily and I already have buckets for both forms in my workflows.  Knowing to send a message at the beginning of a day or towards the end for Contract renewal purposes.  Speaking of which, Contracts take both forms as well, and we haven't put work into Contracts much yet, so even more reason to keep both.  Insurance is another domain where processors are very picky with clarity of something being validUntil (I've seen Insurance contracts specify the validUntil using the last second in an hour for exactness).
> -- 
> 
> Thad
> +ThadGuidry

Received on Wednesday, 8 August 2018 07:27:57 UTC