View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000363210000-011: Historical AccessSpecpublic2016-12-08 13:452022-09-22 20:32
ReporterMatthias Isele Assigned ToPaul Hunkar  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version1.03 
Fixed in Version1.05.03 RC1 
Summary0003632: Part 11 - Determining the first historical data point - specification error
Description

Part 11 - A.2 Determining the first historical data point

states to use the followiong parameters:

returnBounds=false
numValuesPerNode=1
startTime=DateTime.MinValue+1 second
endTime= DateTime.MinValue

So assume the Client runs on windows supporting DateTime values starting at 1601-01-01 12:00AM UTC.
So startTime is set to 1601-01-01 12:00:01AM UTC.

Assume the server runs on a device supporting DateTime values starting at 1970-01-01 12:00AM UTC

Following Part 6 5.2.2.5 DateTime states:
... A date/time is decoded as the earliest time that can be represented on the platform if either
The encoded value represents a time earlier than the earliest time that can be represented with the DevelopmentPlatform’s encoding.

The start date is decoded to 1970-01-01 12:00AM UTC in the server. So startTime and endTime have the same value.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0006594 closedPaul Hunkar "A.2 Determining the first historical data point" conflicts with "6.4.3.2 Read raw functionality" 

Activities

Matthias Isele

2016-12-08 13:52

reporter   ~0007460

I suggest to use the following settings instead to get the first time in history:

returnBounds=false
StartTime=DateTime.MinValue
EndTime=DateTime.MaxValue
numValuesPerNode=1

This would not require any special handling in the server and will work out of the box.
Still a server can handle this as a special case if required.

Rod Stein

2017-05-15 22:46

developer   ~0008036

Fixed in Part 11 1.04 Draft 0

A new method for determining the first historical point has been added.

Added to errata 1.03.4

Jim Luth

2017-06-13 15:39

administrator   ~0008227

Agreed to changes edited in telecon.

Matthias Isele

2017-12-14 06:44

reporter   ~0008794

The proposal was added to the specification as a new option to determin the first data point.
Since the original version of the query is an IOP problem (with embedded devices) we should NOT keep the old query and just add an second way. This will make interoperability even worse.
Please just replace the old version or if absolutly necessary leave both and mark the old version as deprecated.

Jim Luth

2018-10-23 15:59

administrator   ~0009492

We agree that the we should leave both but mark the old way as deprecated.

Paul Hunkar

2022-08-05 06:18

developer   ~0017296

Added text explaining that the minimum value is a special number , as well as cleaning up the definition

Paul Hunkar

2022-08-05 06:26

developer   ~0017297

see related mantis issue

Jim Luth

2022-09-22 20:32

administrator   ~0017817

Agreed to changes edited in F2F meeting.

Issue History

Date Modified Username Field Change
2016-12-08 13:45 Matthias Isele New Issue
2016-12-08 13:52 Matthias Isele Note Added: 0007460
2016-12-20 06:00 Matthias Isele Project Certification => 10000-011: Historical Access
2016-12-20 06:00 Matthias Isele Category IOP Problem => Api Change
2017-01-17 16:41 Rod Stein Category Api Change => Spec
2017-01-17 16:41 Rod Stein Target Version 1.03 =>
2017-01-17 17:37 Jim Luth Assigned To => Rod Stein
2017-01-17 17:37 Jim Luth Status new => assigned
2017-01-17 17:38 Jim Luth Target Version => 1.04
2017-05-15 22:46 Rod Stein Note Added: 0008036
2017-05-15 22:46 Rod Stein Status assigned => resolved
2017-05-15 22:46 Rod Stein Fixed in Version => 1.04
2017-05-15 22:46 Rod Stein Resolution open => fixed
2017-06-13 15:39 Jim Luth Note Added: 0008227
2017-06-13 15:39 Jim Luth Status resolved => closed
2017-12-14 06:44 Matthias Isele Note Added: 0008794
2017-12-14 06:44 Matthias Isele Status closed => feedback
2017-12-14 06:44 Matthias Isele Resolution fixed => reopened
2018-10-23 15:59 Jim Luth Note Added: 0009492
2018-10-23 15:59 Jim Luth Status feedback => assigned
2022-08-05 06:17 Paul Hunkar Relationship added related to 0006494
2022-08-05 06:18 Paul Hunkar Status assigned => resolved
2022-08-05 06:18 Paul Hunkar Resolution reopened => fixed
2022-08-05 06:18 Paul Hunkar Fixed in Version => 1.05.03 RC1
2022-08-05 06:18 Paul Hunkar Note Added: 0017296
2022-08-05 06:23 Paul Hunkar Assigned To Rod Stein => Paul Hunkar
2022-08-05 06:23 Paul Hunkar Status resolved => feedback
2022-08-05 06:23 Paul Hunkar Resolution fixed => reopened
2022-08-05 06:24 Paul Hunkar Relationship deleted related to 0006494
2022-08-05 06:24 Paul Hunkar Status feedback => resolved
2022-08-05 06:25 Paul Hunkar Status resolved => feedback
2022-08-05 06:26 Paul Hunkar Relationship added related to 0006594
2022-08-05 06:26 Paul Hunkar Status feedback => resolved
2022-08-05 06:26 Paul Hunkar Note Added: 0017297
2022-09-22 20:32 Jim Luth Status resolved => closed
2022-09-22 20:32 Jim Luth Note Added: 0017817