[x3d-public] X3D working group meeting: SFTime; Mantis 1103 addition to address durations

[Don Brutzman]

In retrospect, am thinking we should improve the specification definition for SFTime in the specification because "since" does not imply past time.

====================================
https://en.wiktionary.org/wiki/since

Adverb: since (not comparable)

     From a specified time in the past.

Preposition: since

     From: referring to a period of time ending in the present and defining it by the point in time at which it started, or the period in which its starting point occurred.
	1. Continuously during that period of time.
	2. At certain points during that period of time.
====================================

Specification definition appears below.  We could keep that these two paragraphs as written.  Section 5.3.15 SFTime and MFTime should note that

	"When an SFTime value represents a time-interval duration, negative values are not allowed."

and also include reference:

	"See _8.2.2 Time origin_ for further details."

Potential addition to specification appended to existing Mantis issue 1103.

	5.3.15 SFTime and MFTime - Describe two usages
	http://www.web3d.org/member-only/mantis/view.php?id=1103


On 4/25/2018 10:01 AM, Don Brutzman wrote:
> 4. *SFTime design discussion*.  Review of schema constraints on SFTime values uncovered a curious issue.  Background email thread:
> 
>      X3D JSON Schema Updates: determining event constraints for SFTime durations and timestamps
> http://web3d.org/pipermail/x3d-public_web3d.org/2018-April/008609.html
> 
> Summary:  most uses of time values in X3D scenes are for current system clock.  Nevertheless the X3D Abstract Specification allows and defines negative SFTime values as well.
> 
> Key references and excerpts:
> 
> 5.3.15 SFTime and MFTime
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.html#SFTimeAndMFTime
> 
> "Time values are specified as the number of seconds from a specific time origin. Typically, SFTime fields represent the number of seconds since Jan 1, 1970, 00:00:00 GMT. The default value of an uninitialized SFTime field is -1."
> 
> 8.2.2 Time origin
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#Timeorigin
> 
> "Time (0.0) is equivalent to 00:00:00 GMT January 1, 1970. Absolute times are specified in SFTime or MFTime fields as double-precision floating point numbers representing seconds. Negative absolute times are interpreted as happening before 1970. Processing an event with timestamp t may only result in generating events with timestamps greater than or equal to t."
> 
> So X3D functionality includes precise referencing of past and future times.  We had an interesting discussion of various aspects and did not identify any difficulties.
> 
> Summary and resource links can be found in X3D Tooltips.
> 
>      X3D Tooltips: SFTime
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFTime
> 
>> SFTime> Single-field time value in seconds, specified as a double-precision (64-bit) floating point number, 15-17 significant digits, maximum value ~1.8 × 10^308.
>> Example values: 0, 10, or -1 (indicating no actual time value is provided).
>> Hint: Time values are usually either a system time (matching current clock time) or else a nonnegative duration interval in seconds.
>> Hint: Typically, SFTime fields represent the number of seconds since Jan 1, 1970, 00:00:00 GMT.
>> Warning: -1 is default initial value, typically indicating no updated time value has yet been provided.
>> Hint:   X3D Abstract Specification, Time component, 8.2 Concepts for time model, time origin, discrete and continuous changes, time-dependent node cycles and activation, pausing time, etc.
>> Hint: see Wikipedia: Double-precision floating-point format > Hint: see Wikipedia: Time and System time 
> https://en.wikipedia.org/wiki/Double-precision_floating-point_format
> https://en.wikipedia.org/wiki/Time
> https://en.wikipedia.org/wiki/System_time
> 
> No X3D specification changes appear to be needed.  The editors will consider whether to add a cross reference in the abstract specification.
> 
> Related work, independent of SFTime: the Design Printing and Scanning Working Group is considering MetadataDate representations.
> 
> =======================


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman