Yes:
Bits days years
32 49710.26963 136.0993008
31 24855.13481 68.04965042
So signed int 32 = ~68 years
Unsigned Int 32 = ~136
And yes, shifting the origin later than POSIX/Linux origin (01-Jan-1970), as in EPICS time stamp wil add 20+ years.
Thanks, Jeff for the details on timestamps!
Franck
-----Original Message-----
From: Hill, Jeffrey O [mailto:[email protected]]
Sent: 15 February 2012 17:59
To: Hill, Jeffrey O; Di Maio Franck; [email protected]
Subject: RE: Precise time beyond 2038
Already see a mistake
> 0xffffffff sec / (60 sec/min * 60 min/hour * 24 hour/day * 360
> day/year)
0xffffffff sec / (60 sec/min * 60 min/hour * 24 hour/day * 365 day/year)
136 years and therefore 68 years is one half of the range, and rollover in 2126.
> -----Original Message-----
> From: Hill, Jeffrey O
> Sent: Wednesday, February 15, 2012 9:54 AM
> To: 'Di Maio Franck'; [email protected]
> Subject: RE: Precise time beyond 2038
>
> Hi Frank,
>
> The EPICS epoch is 1/1/1990 00:00:00UTC, and therefore one can compute
> the time of the 32 bit _unsigned_ integer seconds rollover event as follows.
>
> 0xffffffff sec / (60 sec/min * 60 min/hour * 24 hour/day * 360
> day/year)
>
> By my calculations (check them for yourself as I just now ran the
> numbers as I was writing this mail) this is about 138 years after the
> epoch which is about 2128.
>
> The codes (see src/libCom/osi/epicsTime.{cpp,h}) that computes time
> stamp differences, and compares timestamps, are carefully written so
> that they produce robust results when the operands are on either side
> of a time stamp rollover as long as the difference between the
> operands does not exceed one half of the full range.
>
> Therefore we hope that projects can operate in time frames near the
> rollover event as long as they don't subtract time stamps that have
> more than 69 years between them.
>
> Jeff
>
> > -----Original Message-----
> > From: [email protected] [mailto:tech-talk-
> [email protected]]
> > On Behalf Of Di Maio Franck
> > Sent: Wednesday, February 15, 2012 8:27 AM
> > To: [email protected]
> > Subject: Precise time beyond 2038
> >
> > Dear all
> >
> > Just to share a worry, get corrections if I am wrong & ideas if any.
> >
> > ITER will run 20+ years or more, so we shall avoid the 2038 limit
> > encountered by time representation that use SIGNED 32 bits integer
> > for seconds (cf. http://en.wikipedia.org/wiki/Unix_time).
> >
> > My understanding is that while time stamps are signed 32 bits
> > integer (+
> a
> > second integer for nanoseconds fraction) it should be OK ....up to
> > 2106 (1970+136y).
> >
> > But to program a "future time event" via CA beyond 2038, no way to
> > use
> an
> > integer for seconds (cannot have better than a signed 32 bits integer).
> So
> > one has to use at least one double.
> >
> > Many variants are possible. With a mantissa of 52 bits (IEEE-64
> > floats), one could in theory use seconds fractions up to 20 bits
> > (microseconds)
> but
> > I expect it is not as simple as that. Anyway, we also need
> > nanoseconds
> so
> > we'll split the time in 2 parts (ex: base + delay).
> >
> > The device support use 64 bits for time in nanos and our OS is Linux
> > x86_64 bits so no other limits.
> >
> > I'll appreciate comments from EPICS freaks having face similar
> questions.
> >
> > Cheers,
> > Franck
> >
> > Franck Di Maio
> > CODAC System Designer
> > CODAC Section
> >
> > ITER Organization, Building 519/027, CHD, Control System Division
> > Route de Vinon sur Verdon - 13115 St Paul Lez Durance - France
> > Phone: +33 4 42 17 64 05
- References:
- Precise time beyond 2038 Di Maio Franck
- RE: Precise time beyond 2038 Hill, Jeffrey O
- Navigate by Date:
- Prev:
RE: Precise time beyond 2038 Hill, Jeffrey O
- Next:
Re: registerRecordDeviceDriver fails at registryRecordTypeFind Matt Rippa
- 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: Precise time beyond 2038 Hill, Jeffrey O
- Next:
EDM segmentation fault in colorInfoClass Shankar, Murali
- 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
|