avr-libc-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]