[LEAPSECS] Bloomberg announced its smear

[Stephen Colebourne]

On 23 September 2016 at 19:35, Brooks Harris <brooks at edlmax.com> wrote:
> So, now there are at least 3 different smears in use by major providers to
> "hide" the Leap Second from downstream systems that might be upset by it.

As I've been saying for years, what we need (desperately) is a
standard for smearing, aka 86400 subdivision days. My preference is
UTC-SLS, but I don't really care so long as it is an agreed standard.
I know that many find smearing offensive, but its timet o move on and
get the standard written.

Stephen


> This produces indeterminate timestamps for the duration of their smears:
>
> Two of them smear for 24 hours, 12 hours either side of the Leap Second
> midnight, but their increments don't match -
>
> Look Before You Leap – The Coming Leap Second and AWS (Updated)
> https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/
>
> Google Leap Smear 2015
> https://mlichvar.fedorapeople.org/leap2015/google_smear.png
>
> Now Bloomberg is smearing for 2000 seconds (or is it 2001 seconds?).
>
> Bloomberg will smear over 2000 seconds after the leap.
> https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf
>
> Meantime Microsoft avoids a smear altogether by diverging from the common
> practice of introducing Leap Seconds on local timescales simultaneous with
> UTC and instead introducing the Leap Second at (the second before) midnight
> in each local zone. This results in integral second increments and a
> symmetrical distribution the Leap Second discontinuity across the local
> YMDhms representations.
>
> The time on Microsoft Azure will be: Different by a second, everywhere
> http://www.theregister.co.uk/2015/05/29/windows_azure_second_out_of_sync/
>
> -Brooks
>
>
>
> On 2016-09-23 10:45 AM, Steve Allen wrote:
>>
>> Bloomberg will smear over 2000 seconds after the leap.
>>
>> https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf
>>
>> They are one of many cloud and financial operations who have,
>> ironically, decided that the non-precision timekeeping through the 1960s
>> (and of POSIX) is preferable to the precise time choice made by the CCIR.
>>
>> --
>> Steve Allen                    <sla at ucolick.org>              WGS-84 (GPS)
>> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
>> +36.99855
>> 1156 High Street               Voice: +1 831 459 3046         Lng
>> -122.06015
>> Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs