[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Missing time.h posix
From: |
Daniele Basile |
Subject: |
Re: [avr-libc-dev] Missing time.h posix |
Date: |
Mon, 12 Oct 2009 12:22:59 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
Frédéric Nadeau ha scritto:
> I once had to write one for a project. It's not that complicated to
> simply convert an 32 bit integer to a GTM time if you cut the corners.
> Since we had no big requirements, here what we had not done:
> - Leap seconds handling
> - Timezone handling
> - Localize printf
>
> Basically we only had unix2struct, struct2unix and a print time function.
>
We had considered also this solution, but we are developing a RTOS (BeRTOS),
that runs on various target, like arm, and we would use a standard posix
library. In this way we not have a time functions custom implementation, and we
believe is more clean to have time.h in avrlibc, like in arm toolchain.
> I think it would be hard to have a library that would match a UNIX
> system. We were always a few second off from a computer but it didn't
> cause any issue for us at the time.
>
That is true, but we think to implement only functions that have sense on avr
target, like mktime.
> if your interested i could post our code, mind you the time to string
> function yield result in French, but that is just some constant string
> to change.
>
I am interested, could you post it, please?
> At the time I was looking to do something decent for asctim() but then
> it depends on where you are in the world for daylight saving as well
> as the mood of the head of the country to decide to change the dates
> at which saving day light is used. I know OpenBSD uses a file in /etc
> to solve the issue. It's only 34bytes(fits well in either
> ram/programspace/eeprom) but it's only for /Canada/Eastern. It became
> quite complicated for our requirements at the time.
>
I have see newlib implementation of asctime and they use standard
representation, without localize the time string. I am in accord to this
implementation, because we only use time.h conversion functions, and day light
is already considered in unix time that you use. Otherwise if you want localize
time string you could use tm structure and implement your custom time string
representation. I believe that in most case you doesn't need to localize time
string representation.
--
| [D]-o Ing. Daniele Basile - address@hidden
| ||}-o Develer S.r.l., R&D dept.
| [B]-o http://www.develer.com - http://www.bertos.org