<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>How stored date and time information?</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/32815/how-stored-date-and-time-information</link><description> 
On STM32F1 I need create a log with storing the EEPROM, any as 

 
30.10.2015 17:30 temp, humidity, xx, xx ,xx 
30.10.2015 17:45 temp, humidity, xx, xx ,xx 

 
I wonder how to store time information? 
I do not use Linux int32 (time_t) since 2038 is</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: How stored date and time information?</title><link>https://community.arm.com/thread/93564?ContentTypeID=1</link><pubDate>Sat, 26 Sep 2015 17:41:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a11af283-287a-4e5f-b7f0-0e46308feb0d</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;many RTC implementation just deal with 1901 thru 2099 as it
simplifies the leap year logic.&amp;quot;&lt;/p&gt;

&lt;p&gt;
The RTC tends to be the weak links. How to set the initial time.
How to handle drift. How to handle leap years. Leap seconds. Time
zones. Daylight savings. Over-the-air or networked protocols. Power
failures/battery changes. Moving the device over a time zone boundary
or date boundary. Logging when RTC was synchronized, and how much
forward/backwards the time was corrected. How long the RTC may be
allowed to operate standa-lone without synchronization. How to know
if the supply voltage is high enough that the RTC operation can be
trusted.&lt;/p&gt;

&lt;p&gt;
There are so many assumptions that needs to be documented. So many
things that has to be either ignored or
supported/tested/documented/...&lt;/p&gt;

&lt;p&gt;
The time stamps of the individual measurements aren&amp;#39;t worth much
if there isn&amp;#39;t confidence in the time used by the RTC.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How stored date and time information?</title><link>https://community.arm.com/thread/64130?ContentTypeID=1</link><pubDate>Sat, 26 Sep 2015 16:29:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7f5d3fef-2be4-4ea9-be0b-211e11653fc9</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
As Per points out 32-bit 1970 Epoch numbers go out to 2106, many
RTC implementation just deal with 1901 thru 2099 as it simplifies the
leap year logic.&lt;/p&gt;

&lt;p&gt;
Windows has a 64-bit format&lt;/p&gt;

&lt;p&gt;
Doing calendering from any epoch isn&amp;#39;t that complicated, though a
lot of people do screw it up, and don&amp;#39;t test their code, so you
should always verify the corner cases on stuff you pick up off the
internets.&lt;/p&gt;

&lt;p&gt;
The 2038 thing is a bit of a red herring, sure some old crap is
going to fail, but anyone putting any thought into things will be
fine.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How stored date and time information?</title><link>https://community.arm.com/thread/69370?ContentTypeID=1</link><pubDate>Sat, 26 Sep 2015 10:49:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2198ef55-7a77-473a-bb48-52f1471fa5a2</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
What does it matter that 2038 is next door?&lt;/p&gt;

&lt;p&gt;
Are you afraid that your device will fail to know if it has
temperature values from 2038 or if the recorded value is from
20:45:52 Friday 13 December 1901?&lt;/p&gt;

&lt;p&gt;
Is it really (?) a problem for your software to figure this out?
Will you really (?) have a log that already today contains readings
from before 1970?&lt;/p&gt;

&lt;p&gt;
The magic thing happening in 2038 is just that a signed 32-bit
time value will become negative - if treated as 32-bit unsigned,
you&amp;#39;ll manage until the year 2106.&lt;/p&gt;

&lt;p&gt;
And if you decide to use time base 2015-01-01 00:00:00 as &amp;quot;time
zero&amp;quot; instead of the unix epoch of 1970-01-01 00:00:00, then an
unsigned 32-bit will give you an additional 45 years meaning your
poor logger will have time stamp values turning around in 2151.&lt;/p&gt;

&lt;p&gt;
So exactly how long do you expect to keep that recorder running,
before it gets too old and should be replaced with a newer device? If
you have ample room in your EEPROM, you could use a 48-bit or 64-bit
value instead of a puny 32-bit integer. In the end, a binary value
ticking one step per second is the smallest storage format you can
use to store time with one-second resolution. Then you just need to
decide how many bits wide that binary value should be, and the
correlation between the value zero and some &amp;quot;normal&amp;quot; almanac
time.&lt;/p&gt;

&lt;p&gt;
In your posted examples, it doesn&amp;#39;t even seem like you need
one-second resolution, given that you posted times in minutes - and
with 15 minutes between the two samples. A 16-bit unsigned integer
where each tick represents 5 minutes would cover 65535*5 minutes
which is over 227 years. If it ticks with a 15-minute quantum it
would cover 682 years. And if you always sample at a fixed time
interval, you don&amp;#39;t even need to store the individual time stamps -
it&amp;#39;s enough to store the start time and then just store the
temperature values. Just remember what to do if you need to replace
the battery, since rather few microcontroller-based devices actually
manages hundreds of years of uninterrupted service...&lt;/p&gt;

&lt;p&gt;
If your samples are taken at irregular times you can still avoid
storing huge absolute times for each sample by instead storing the
delta time since the previous sample. You could maybe store a full
time stamp every 100 samples to avoid the need to run through the
full sequences of samples just to be able to compute the time stamp
for the final reading.&lt;/p&gt;

&lt;p&gt;
So why do you end up seeing lots of problems with your data
logger? Isn&amp;#39;t the world full of solutions where a huge number of
different solutions all will be good enough? There almost never
exists any &amp;quot;best&amp;quot; solution to a problem - &amp;quot;best&amp;quot; just depends too
much on the specific needs. And you haven&amp;#39;t described your specific
needs - you probably haven&amp;#39;t even yourself figured out what your
specific needs are.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>