1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: [EXTERNAL] Archiver getDataAtTime and getData endpoints have a timestamp discrepancy |
From: | "Zimmermann, David Daniel via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "De La Paz, Elena" <delapaz3 at llnl.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 10 Aug 2021 14:48:48 +0000 |
Have you tried something like UNIXSECONDS FOR SECS OF VAL 3 + 1? There might be an issue of it using something like “<” rather than “<=”.
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "De La Paz, Elena via Tech-talk" <tech-talk at aps.anl.gov> Hi all, I have a question about using the different endpoints and the timestamp resolution of the archiver. Here is the situation that is confusing me:
Example response for pv ID: [{ val: “2”, secs: “1627576833”, nanos: “342322864”}, {val: “3”, secs: “1627576922”, nanos: “563728637”} ]
Example request: <ARCHIVER DATA ENDPOINT>/getDataAtTime?at=<UNIXSECONDS FOR SECS OF VAL 3>.563728637 -d [“ID”]
Example response: { “ID”: “2”} This occurs over shot intervals, so time zone issues are not the underlying cause. Is there some difference in the time resolution of the different endpoints? Is this a quirk of the archiver? We are doing a work around by rounding up to
milliseconds, but it is confusing that the timestamp returned in nanoseconds can’t be used precisely in getdataattime Thank you, Elena De La Paz |