Docs at page 7 of 
https://datasheets.maximintegrated.com/en/ds/DS1921H-DS1921Z.pdf 
<https://datasheets.maximintegrated.com/en/ds/DS1921H-DS1921Z.pdf> are not very 
clear, but I would bet that
1 = Jan
2 = Feb
…

so that conversions at 
https://github.com/owfs/owfs/blob/ba66022f115909396a4b939f37e8c3ee8d293862/module/owlib/src/c/ow_1921.c#L1014
https://github.com/owfs/owfs/blob/ba66022f115909396a4b939f37e8c3ee8d293862/module/owlib/src/c/ow_1921.c#L1072
 
<https://github.com/owfs/owfs/blob/ba66022f115909396a4b939f37e8c3ee8d293862/module/owlib/src/c/ow_1921.c#L1072>
are off by one.

The best way to test for this is simply set the RTC at 23:59 and observe how 
the day/month registers are incremented. Actual code assumes that we have

Day31 Month00 -> Day01 Month01
Day28 Month01 -> Day01 Month02

but there is the possibility that the registers actually go

Day31 Month01 -> Day01 Month02
Day28 Month02 -> Day01 Month03

Stefano

BTW, I never really understood why in C the broken down time struct_tm has days 
numbered from 1 to 31, but month numbered from 0 to 11:

struct tm {
        int     tm_sec;         /* seconds after the minute [0-60] */
        int     tm_min;         /* minutes after the hour [0-59] */
        int     tm_hour;        /* hours since midnight [0-23] */
        int     tm_mday;        /* day of the month [1-31] */
        int     tm_mon;         /* months since January [0-11] */
        int     tm_year;        /* years since 1900 */
        int     tm_wday;        /* days since Sunday [0-6] */
        int     tm_yday;        /* days since January 1 [0-365] */
        int     tm_isdst;       /* Daylight Savings Time flag */
        long    tm_gmtoff;      /* offset from UTC in seconds */
        char    *tm_zone;       /* timezone abbreviation */
};

the most common explanation being that tm_mday is always used as is, but tm_mon 
is mostly used as an index in an array of month names, thus starting from 0.

> On 22 Aug 2018, at 19:50, Jan Kandziora <j...@gmx.de> wrote:
> 
> Am 22.08.2018 um 16:16 schrieb Ben Oliver:
>> I'm having issues with clock settings on a DS1921 going from windows to
>> owfs on linux, and vice-versa.
>> 
>> I (on owfs) set the time like this:
>> 
>>    echo "$(date +%s)" > "clock/udate"
>> 
> Which version of owfs do you use?
> 
> $ owfs --version
> 
> 
> 
> Owlib (owfs) uses gmtime_r() to turn the seconds till 1970-01-01 UTC
> into a representation the DS1921 understands.
> 
> https://github.com/owfs/owfs/blob/master/module/owlib/src/c/ow_1921.c#L1065
> 
> This function assumes January == 0.
> 
> Unfortunately, the DS1921 datasheet does not state whether January is 0
> or 1. Others have the same problem:
> 
> https://github.com/dustin/ibutton/blob/master/mlan/ds1921.c#L53
> 
> 
> So far, I see only one way to find it out who's correct, check whether
> the February, 29th correction the chip does works right with owlib or not.
> 
> Volunteers? Maybe Paul (or others) had checked that already in the past?
> 
> Kind regards
> 
>       Jan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to