RE: Precise time beyond 2038

[<mic...@di...>]

From: White, Greg [mailto:gr...@sl...]
> This seems like a sophisticated suggestion for internal representation
> of time. Can I ask
> how this suggestion relates to the original issue of *James'* archiver
> service user interface,
> and *Ralph's* point about delta times from UTC? I'm having a hard time
> relating the
> tech stuff to what I'd be expected to type to do work:

Sorry, regarding the original issues, it's a red herring.  I'm just talking about binary transport and representation, not part of what we were discussing yesterday.

> Let me give a use case and ask you to comment on what your proposal
> means for time
> specifications in that use case. What a user has to type and what they
> expect to get:
> 
> UC: Say I want to get archive data between one time and another, and
> plot it. Say I use
> the notional eget tool. For clarity, let's illustrate how I would get
> data into a file,
> and then plot it with gnuplot, 2 lines from the command line:
> 
>    $ eget -s archiveRPC -t0 2012-02-14T11:12:30Z -t1 2012-02-14T11:12:40Z QUAD0 > quad0history.dat
>    $ echo 'plot quadhistory.dat using 1:2' | gnuplot -persisit
> 
> So, given your suggestion, what would be the form of the t0 and t1
> parameter values,
> and what would be the contents of the 1st (times) column of
> quadhistory.dat?

Well, the data returned in quad0history.dat would need to be in a format understood by gnuplot, so that's another story.

There's nothing wrong with your parameter values, and that's completely unaffected by my remark about internal representation.  There remains the question of timezone conversion ...

> How would what I type be modified in the light of *Ralphs* request that
> he be able to
> specify UTC plus a delta.

There are two further choices.  Let's imagine that you're in a time zone somewhat to the west of me, then the following three options for t0 would presumably be equivalent:

1.	-t0 2012-02-14T11:12:30Z
2.	-t0 2012-02-14T06:12:30-05:00
3.	-t0 2012-02-14T06:12:30

I think Matej's point yesterday is that (3) is ambiguous, particularly if you don't know whether the date in question was subject to daylight saving time.  Yesterday we were proposing that (1) and (3) be equivalent, and I guess (2) is a sound option.

(The timezone extension is a bit confusing -- you have to subtract the extension value to get UTC time.)

> Thanks
> Greg
> 
> On 16 Feb 2012, at 08:57, <mic...@di...> wrote:
> 
> > For EPICS v4 I'd like to make a simple suggestion for absolute time
> stamp representation: we can represent time as nanoseconds in the EPICS
> epoch (or, actually, the UNIX epoch would work just as well) in a
> single 64-bit integer.  At 3.1e7 seconds in a year, 2^63 (let's forget
> about the top bit for a moment) = 9e18 ns = 9e9 s = 300 years.  This
> should keep us going.
> >
> > A big advantage of this representation is that arithmetic is easy and
> it is a single integer quantity, so easy to represent, store,
> transport, and manipulate.
> >
> > Whether the timestamp type (let's call it epics_time_t perhaps) is
> signed or unsigned, and whether we use the UNIX or EPICS epochs are
> arguable.  Personally I'd like to suggest using the UNIX epoch, we can
> now afford the 20 years, and it would cause less confusion with C.
> >
> > So just for reference here are a couple of suggested implementations
> (assuming signed and UNIX epoch):
> >
> > 	typedef int64_t epics_time_t;
> >
> > 	epics_time_t timespec_to_epics_time(const struct timespec *ts)
> > 	{
> > 	    return (epics_time_t) 1000000000 * ts->tv_sec + ts->tv_nsec;
> > 	}
> >
> >
> > From: tec...@ap... [mailto:tech-talk-
> >> 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.
> >
> > If you represent current time in the Unix EPOCH using doubles you'll
> only get microsecond precision, as you point out there's only 52 bits
> of precision available.  I guess that's why you move on...
> >
> >> 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).
> >
> > This suggestion makes me wince, which is why I wrote my message
> above.  I currently use microseconds in 64-bits, but a little
> arithmetic told me we can afford nanoseconds as I suggest here.
> >
> >
> >> 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.
> >
> > --
> > This e-mail and any attachments may contain confidential, copyright
> and or privileged material, and are for the use of the intended
> addressee only. If you are not the intended addressee or an authorised
> recipient of the addressee please notify us of receipt by returning the
> e-mail and do not use, copy, retain, distribute or disclose the
> information in or attached to the e-mail.
> > Any opinions expressed within this e-mail are those of the individual
> and not necessarily of Diamond Light Source Ltd.
> > Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for
> any damage which you may sustain as a result of software viruses which
> may be transmitted in or with the message.
> > Diamond Light Source Limited (company no. 4375679). Registered in
> England and Wales with its registered office at Diamond House, Harwell
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
> Kingdom
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> ---------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom