And there is 32 bits for user specification - so the new time format is
64 bit seconds, 32 bit nsecs, 32 bit user
-----Original Message-----
> To sum up the type aspect:
> - A pair of integer is required& signed integers are good enough for
now ... provided that UINT32 support is completed within the next 68
years.
> - Relative time (pulse time), with ns precision can fit in a FLOAT64
for 125 hours or something like that, which would be OK for us.
> - A ns precision for a software interrupt is somehow excessive and
microsecond precision would fit into a FLOAT64 mantissa but it's not
very good to have many resolutions.
>
> We are considering a waveform with 2 ints for time PVs and maybe
FLOAT64 records for relative time (pulse time).
>
> I also guess that pvData will/shall allow time struct with ns
fractions in the API.
>
pvData defines a timeStamp that is similar to epics except that seconds
after epoch is
1) An 64 bit signed integer rather than 32 bit signed integer. This
prevents overflow for a really really long time.
2) epoch is posix epoch (Jan 1 1970 at 00:00:00 UTC) rather than epics
epoch (Jan 1 1990 at 00:00:00 UTC)
The nanoseconds within the second is a signed 32 bit integer.
- References:
- Manipulating time in records Di Maio Franck
- Re: Manipulating time in records Luedeke Andreas
- RE: Manipulating time in records Di Maio Franck
- Re: Manipulating time in records Marty Kraimer
- Navigate by Date:
- Prev:
RE: Lookup table problem Dalesio, Leo
- Next:
Re: Lookup table problem Ralph Lange
- 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
- Navigate by Thread:
- Prev:
Re: Manipulating time in records Marty Kraimer
- Next:
Re: Manipulating time in records Luedeke Andreas
- 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
|