Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost.DateTime and leap year/leap seconds
From: Jeff Garland (azswdude_at_[hidden])
Date: 2015-07-21 12:35:25


Ah yes, CCSDS -- well familiar with it working on satellite systems myself
:) As for ntp -- obviously that can get *very sticky* since you really have
no idea when it's going to adjust the clocks. Here's an article from the
leap second we just had on current state of some common platforms...ugly...

https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/

Personally I feel it's so much smarter to have the timing systems run a
'steady_clock' in c++11 parlance -- a non-leap second adjusted like GPS or
TAI and then allow software to convert to UTC for user consumption as
needed. But I realize you might not have control over that. And note, you
may be able to use a c++11 steady_clock

Getting back to the calculation at hand, you're on the correct course --
all I'd say is 'convert the leap second at the boundaries' and calculate in
a monotonic, fixed time reference. This makes the calculation just a
standard calculation and the result can be trivially converted back to a
leap second adjusted utc as desired. By analogy, consider the 'time zone
example' from the docs to calculate the 'local arrival time' of a flight
from phoenix to new york. Internally the code damps out all the
complications associated with daylight savings time, etc by internally
converting any local times to utc internally on construction -- then any
calculations are simple adds and subtracts -- and then to get a new local
reference you convert from the utc reference back out (see the 'just
integer math here -- even though these are 'local times' internally utc is
stored and all duration calculations just do ratio adjusted addding).

 time_zone_ptr phx_tz(new posix_time_zone("MST-07:00:00"));

  //local departure time in phoenix is 11 pm on april 2 2005
  // (ny changes to dst on apr 3 at 2 am) local_date_time
phx_departure(date(2005, Apr, 2), hours(23),
                                phx_tz,
                                local_date_time::NOT_DATE_TIME_ON_ERROR);

  time_duration flight_length = hours(4) + minutes(30); //just integer
math here!!!
  local_date_time phx_arrival = phx_departure + flight_length;
  local_date_time nyc_arrival = phx_arrival.local_time_in(nyc_tz);
//convert from utc to ny local

Exact same approach works with leap seconds -- convert your .60 second into
a fixed reference system like gps -- do any duration math -- and convert
back out to utc. For me, I'd formalize all this in something like a leap
second aware 'tm' struct -- something like this....

   struct leap_tm {
      leap_tm(int year, int milliseconds, int microseconds, bool
leap_adjusted) :
      {
         //convert to leap or non leap ptime representation
         //use leap second 'table' to convert to utc
       }
      ptime as_non_leap_adjusted_utc() {...}
      ptime as_utc() {...}

    }

Note that there's a good chance that this will be a real feature in boost
date-time 2.0, but time of arrival for bdt2 is not known. Hope this
helps...

Jeff

On Tue, Jul 21, 2015 at 2:24 AM, Auer, Jens <jens.auer_at_[hidden]> wrote:

> Hi Jeff,
>
>
>
> The specification we got is a bit vague. Basically I am getting data
> packets from a server which puts a time stamp in the data which is defined
> as “microseconds in the current year”. From that, I have to create a
> time-stamp in a different format which is CCSDS day segmented time (epoch
> is 1.1.1958, 16-bit days, 32-bit milliseconds of the year and 16-bit
> microseconds of the millisecond). I can assume that both systems are
> synchronized via ntp, so I guess it is UTC. I am trying to get more
> details on that.
>
>
>
> What I then need to do is to write a function that computes
>
> convert(microseconds) -> (days since 1.1.1958, milliseconds, microseconds)
>
>
>
> My idea was to:
>
> 1. Decide which is the current year. When the two systems disagree,
> the data server takes precedence because it provides a more accurate clock
> internally.
>
> 2. From this year, compute the number of days from 1.1.1958 to 1.1.
> This could something like
> d = ptime(date( /* 1.1. of current year */) ) + microseconds(x)
>
> 3. Compute the number of days in the current year from the number of
> microseconds.
> days = d.date().day_of_year()
>
> 4. Compute the milliseconds/microseconds in the current day from
> d.time_of_day().
>
>
>
> The question about leap seconds came up when converting the microseconds
> in the current year to the day. I guess that the original microseconds
> value contains leap seconds, but I need to get a definite statement for
> this.
>
>
>
> However, I am currently not implementing the conversion, but proposing how
> to do it (we need to write detailed design documents first…). I wanted to
> use Boost.DateTime and include a statement that when I convert the number
> of microseconds to days, leap seconds are taken into account.
>
>
>
> Best wishes,
>
> Jens
>
>
>
> *--*
>
> *Dr. Jens Auer *| CGI | Software Engineer
>
> CGI Deutschland Ltd. & Co. KG
> Rheinstraße 95 | 64295 Darmstadt | Germany
>
> T: +49 6151 36860 154
>
> jens.auer_at_[hidden]
>
> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
> unter de.cgi.com/pflichtangaben.
>
>
>
> CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
> CGI Group Inc. and its affiliates may be contained in this message. If you
> are not a recipient indicated or intended in this message (or responsible
> for delivery of this message to such person), or you think for any reason
> that this message may have been addressed to you in error, you may not use
> or copy or deliver this message to anyone else. In such case, you should
> destroy this message and are asked to notify the sender by reply e-mail.
>
>
>
> *From:* Boost-users [mailto:boost-users-bounces_at_[hidden]] *On
> Behalf Of *Jeff Garland
> *Sent:* 15 July 2015 01:09
> *To:* boost-users_at_[hidden]
> *Subject:* Re: [Boost-users] Boost.DateTime and leap year/leap seconds
>
>
>
> Hi Jens -
>
>
> Leap second support never got added to the library -- most applications
> can ignore them. In principle, of course, you can use the library to help
> you do the calculations. Basically they are like leap years except that
> they are irregular -- so you have to use a collection to perform the
> adjustment instead of an algorithm.
>
> Little confused about the use case though -- are the microseconds you
> receive including the leap seconds or not including them? Basically which
> way are you adjusting?
>
> Jeff
>
>
>
> On Fri, Jul 10, 2015 at 5:10 AM, Auer, Jens <jens.auer_at_[hidden]> wrote:
>
> Hi,
>
>
>
> I am considering using Boost.DateTime in one of my projects, and there
> have been some concerns about handling leap seconds on the customers side.
> The documentation says that other libraries do not handle leap seconds
> correctly, but it does not state that Boost.DateTime does. I found only one
> mail from 2009 on the mailing list asking about leap seconds, but this does
> not give an answer. Does anybody have some information on this?
>
>
>
> The computations I intend to do are actually rather limited. I will be
> given a year and a number microseconds, and have to compute the day in the
> year that this describes from the start of the year, together with
> microseconds and milliseconds in the day. So what I want to implement is a
> function tuple<days, milliseconds, microsends> convertTime(year,
> microseconds).
>
>
>
> Best wishes,
>
> Jens
>
>
>
> *--*
>
> *Dr. Jens Auer *| CGI | Software Engineer
>
> CGI Deutschland Ltd. & Co. KG
> Rheinstraße 95 | 64295 Darmstadt | Germany
>
> T: +49 6151 36860 154
>
> jens.auer_at_[hidden]
>
> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
> unter de.cgi.com/pflichtangaben.
>
>
>
> CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
> CGI Group Inc. and its affiliates may be contained in this message. If you
> are not a recipient indicated or intended in this message (or responsible
> for delivery of this message to such person), or you think for any reason
> that this message may have been addressed to you in error, you may not use
> or copy or deliver this message to anyone else. In such case, you should
> destroy this message and are asked to notify the sender by reply e-mail.
>
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net