str9.rtc code missing?
Locked
 
|
Martin Guy |
str9.rtc code missing?
|
|
|
jbsnyder |
Re: str9.rtc code missing?
|
|
|
|
Martin Guy |
Re: str9.rtc code missing?
|
|
|
|
jbsnyder |
Re: str9.rtc code missing?
|
|
|
|
Martin Guy |
Re: str9.rtc code missing?
|
|
On 29 August 2011 20:12, James Snyder <[hidden email]> wrote:
> On Mon, Aug 29, 2011 at 11:30 AM, Martin Guy <[hidden email]> wrote: >>> Are you suggesting using os.date to handle getting of date/time >> >> yes. If we can just implement existing Lua conventions (such as LFS >> for filesystem operations, os.* for date operations and so on), that >> is not only more elegant, but improves the chances of standard Lua >> code working in eLua. OK, we have to invent os.setdate() simply >> because Lua os.*() doesn't provide that, but the path of least >> resistence is to adopt the existing conventions for handling dates and >> times. > > So, are you suggesting that os.setdate would just take the table form > (the "*t") format? (http://www.lua.org/pil/22.1.html) they don't handle the time and the date respectively (!). time() reads the system date and time and returns it as a coded number or converts from the a table {year, month, day, hour, min, sec} to the coded representaton, while date() does basically the opposite. What strange naming! As regards avoiding pulling in too much C library, I think we get gmtime() and mktime() anyway because some RTCs store the time internally as separate fields (e.g. DS1337) while systems without an RTC chip will count time linearly in some way, such as counting a systick interrupt, so I think we have to be able to convert between coded time and tables anyway. > I guess what I was getting at was just that if we have to pick a > locale for handling both printing ("%x" or "%X") and maybe parsing > that instead of supporting all the possible locales out there, we just > pick a sane one that's a standard. The manual says that "the representations for %x, %X, and %c change according to the locale and the system." so I think here we have a free hand. The order of the fields in ISO 8601 has the advantage of being unambiguous everywhere, while any choice of mm/dd/yy or dd/mm/yy will be wrong somewhere. Not to mention being Y2K-bugged. Who designed this awful part of the Lua library?! Sadly, the examples in PIL print dates with slashes XX/XX/XX XX:XX:XX whereas ISO 8601 advocates hyphens XXXX-XX-XX XX:XX:XX. Since no program could ever read and understand the output of %c or %x, given its variability, I think we can call it human-readable only, so can do what we want. I suggest YYYY-MM-DD and HH:MM:SS as per ISO > Presumably we would support all the > other formatting options to get individual components into a string. > It looks like Lua uses strftime for handling those (which is in > Newlib, not sure how much code size it takes up). > > So, I guess there are a couple things here: > 1) For os.date do we support all that strftime usually provides, > including locales, ditto but with a fixed locale, or just the table > format? I'd make os.date() exactly the same as standard Lua (well, just enable os.date() in the Lua source - it makes no calls to the OS). That way more standard Lua code will work in eLua. Locales are not an option for us due to their size - 6MB on Unix - so isdst is always returned false (or just undefined==nil==false) and we can just ignore it if they pass it to os.time(table). > 2) For os.setdate do we support all the formatting options for date > strings including locales, ditto but with a fixed locale, or just the > table format? There are locales (language options such as date-printing order and whether floating point values are printed with a dot or a comma at the decimal point) and there are also timezones (when to apply daylight saving time, how many hours to offset from UTC). I don't think an embedded target has space for tables of timezones (6MB) or for language options (either. Parsing date strings is not a requirement. Nothing in Lua does this, it's incredibly complex and we don't have locale information (language tables are (timezone tables for isdst are 6MB on Unix) to be able to do it. At the Lua level, I suggest os.settime() either: 1) take a coded value, the same thing that os.time() returns, so that os.settime(os.time()) is (almost) a no-op and if a program wants to set the date and time using separate fields, it can use os.settime(os.date(table)), 2) or take either a number or a table and do the implicit call to os.date() for you. I'd tend towards the simpler option 1). I suppose the C platform layer should decide on one format, which I guess is the system-dependent number, as returned by os.time(). > I suppose > we could provide options as we do for other things though for targets > with smaller flash availability? You mean BUILD_OSDATE or something? I think, if a program deals in time/date at all, it's probably because it wants to display it somewhere. Making the whole time/date subsystem conditionally compiled might make more sense, since eliminating it all that drops all the gmtime()/mktime() stuff as well. There is other stuff in the os library too: os.clock() (elapsed time since the program started - fairly easy to implement once you have time/date stuff) os.difftime(t1, t2) - pretty easy if our coded numbers are in seconds. and I was already thinking of implementing the os library's file operations for systems with an mmc card: os.remove(filename) os.rename(oldname, newname) os.tmpname() but commenting out the lines that map those functions at the end of loslib.c should be enough until the day we inplement them. As regards code size, attached are versions of mktime() and gmtime() which use a sophisticated algorithm but don't do timezones. The newlib versions are pretty dumb, just looping from year to year, adding month sizes and testing for leap years, while these calculate the answers directly. Including these in the build replaces the ones in newlib and is 1700 bytes smaller (oh, and faster :). If you also disable the handling of negative times in this code (for dates before 1970), you save another 68 bytes. You'll also want to remove the call to localtime() in src/lua/loslib::os_date(). Or provide a stub in the file that just calls gmtime(). if (*s == '!') { /* UTC? */ stm = gmtime(&t); s++; /* skip `!' */ } else stm = localtime(&t); but I suggest leaving the "!"-skipping code, again so that standard Lua programs or libraries are more likely to work in eLua. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
mkgmtime.c (7K) |
|
BogdanM |
Re: str9.rtc code missing?
|
|
|
|
Martin Guy |
Re: str9.rtc code missing?
|
|
| Free forum by Nabble | Edit this page |