bugAVR C Runtime Library - Bugs: bug #44519, Use int64_t for time_t and an...

 
 

bug #44519: Use int64_t for time_t and an earlier epoch than 2000-01-01 00:00:00

Submitted by:  Gregor Riepl <onitake>
Submitted on:  Thu 12 Mar 2015 03:11:29 PM UTC  
 
Category: LibrarySeverity: 3 - Normal
Priority: 5 - NormalItem Group: libc code
Status: NonePercent Complete: 0%
Assigned to: NoneOpen/Closed: Open
Release: UnknownFixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 12 Mar 2015 03:11:29 PM UTC, original submission:

This feature request applies to avr-libc 1.8.1. (the bug tracker does not list this version)

avr-libc contains an implementation of the POSIX/ISO C time API. The documentation states that, due to limitation of the 8bit AVR architecture, some corners were cut and the API is limited in respect to ISO C.

This generally ok, but time_t is represented by an unsigned 32bit integer. This runs contrary to efforts to modernize the C time API. Most modern C runtime library implementors have opted to use a signed 64bit integer, which avoids the "Year 2038 Problem". avr-libc avoids this problem differently, at a cost: The time epoch is defined as midnight Jan 1 2000, and time_t is an unsigned type. This allows for dates up to Feb 2136 to be represented, but earlier dates than Jan 2000 are invalid.

While doing calculations on 64bit quantities bears a performance cost on an 8bit architecture, that cost is relatively small for most operations. For what it's worth, the same applies to 32bit quantities anyway. Also, modern compiler handle the "emulation" of 32bit and 64bit arithmetic automatically.

With these things in mind, I request that the avr-libc time implementation be changed to use a signed 64bit type to represent a timestamp (time_t), and the epoch be changed to an earlier date than Jan 1 2000, such as the Unix epoch (midnight Jan 1 1970) or a different commonly used one (Jan 1 1900, Jan 1 1601). Allowing for negative timestamps to represent valid dates is also a possibility.

Gregor Riepl <onitake>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by onitake (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1