All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Salyzyn <salyzyn@android.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>,
	rtc-linux@googlegroups.com
Subject: [rtc-linux] Re: rtc-palmas: correct for bcd year
Date: Mon, 4 Jan 2016 08:45:54 -0800	[thread overview]
Message-ID: <568AA1C2.2070407@android.com> (raw)
In-Reply-To: <20160104161853.GC32724@piout.net>

On 01/04/2016 08:18 AM, Alexandre Belloni wrote:
> Hi,
>
> On 30/12/2015 at 12:51:45 -0800, Mark Salyzyn wrote :
>> Replace bcd2bin and bin2bcd with one that maps years 1970 to 2129
>> in a pattern that works with the underlying hardware.
>>
>> The only transition that does not work correctly for this rtc clock
>> is the transition from 2099 to 2100, it proceeds to 2000. The rtc
>> clock retains and transitions the year correctly in all other
>> circumstances.
>>
> If that transition doesn't work, it is not useful to try to support
> dates after 2099. Also, I'm concerned about the leap year handling in
> the other case. What is done right now is probably the best however, I
> couldn't find the datasheet to confirm.
>

As it stands today, if I set the date to 1970, it returns 2066, so this 
is a leap(sic) forward for this one rtc clock.

The advantages of supporting 2099+ for being able to set those years and 
not return garbage like in the 1970 case. The failure to roll over from 
2099-2100 is but a millisecond of failure for an additional 1/3 of 
century of well being, and support code is minor, albeit flawed. Without 
these additional four lines, if something sets the year to 2100, they 
will get a garbage back in return, a small price to pay IMHO.

There are dozens and dozens of other bcd-based rtc clocks that could 
gain from this example (and may not have this issue with 2099 rollover), 
so maybe this year code should be in the library?

I will remove 2099+ support if you continue to consider this rollover 
issue egregious given my rationalization.

Sincerely -- Mark Salyzyn

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Salyzyn <salyzyn@android.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>,
	rtc-linux@googlegroups.com
Subject: Re: rtc-palmas: correct for bcd year
Date: Mon, 4 Jan 2016 08:45:54 -0800	[thread overview]
Message-ID: <568AA1C2.2070407@android.com> (raw)
In-Reply-To: <20160104161853.GC32724@piout.net>

On 01/04/2016 08:18 AM, Alexandre Belloni wrote:
> Hi,
>
> On 30/12/2015 at 12:51:45 -0800, Mark Salyzyn wrote :
>> Replace bcd2bin and bin2bcd with one that maps years 1970 to 2129
>> in a pattern that works with the underlying hardware.
>>
>> The only transition that does not work correctly for this rtc clock
>> is the transition from 2099 to 2100, it proceeds to 2000. The rtc
>> clock retains and transitions the year correctly in all other
>> circumstances.
>>
> If that transition doesn't work, it is not useful to try to support
> dates after 2099. Also, I'm concerned about the leap year handling in
> the other case. What is done right now is probably the best however, I
> couldn't find the datasheet to confirm.
>

As it stands today, if I set the date to 1970, it returns 2066, so this 
is a leap(sic) forward for this one rtc clock.

The advantages of supporting 2099+ for being able to set those years and 
not return garbage like in the 1970 case. The failure to roll over from 
2099-2100 is but a millisecond of failure for an additional 1/3 of 
century of well being, and support code is minor, albeit flawed. Without 
these additional four lines, if something sets the year to 2100, they 
will get a garbage back in return, a small price to pay IMHO.

There are dozens and dozens of other bcd-based rtc clocks that could 
gain from this example (and may not have this issue with 2099 rollover), 
so maybe this year code should be in the library?

I will remove 2099+ support if you continue to consider this rollover 
issue egregious given my rationalization.

Sincerely -- Mark Salyzyn

  reply	other threads:[~2016-01-04 16:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 20:51 [rtc-linux] rtc-palmas: correct for bcd year Mark Salyzyn
2015-12-30 20:51 ` Mark Salyzyn
2016-01-04 16:18 ` [rtc-linux] " Alexandre Belloni
2016-01-04 16:18   ` Alexandre Belloni
2016-01-04 16:45   ` Mark Salyzyn [this message]
2016-01-04 16:45     ` Mark Salyzyn
2016-01-05  0:00     ` [rtc-linux] " Alexandre Belloni
2016-01-05  0:00       ` Alexandre Belloni
2016-01-05 16:08       ` [rtc-linux] " Mark Salyzyn
2016-01-05 16:08         ` Mark Salyzyn
2016-07-08 14:10         ` [rtc-linux] " Alexandre Belloni
2016-07-08 14:10           ` Alexandre Belloni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568AA1C2.2070407@android.com \
    --to=salyzyn@android.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rtc-linux@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.