Re: os.time() unable to read in UTC times

[Gerhard Sittig <Gerhard.Sittig@...>]

On Fri, May 02, 2008 at 14:46 +0300, Asko Kauppi wrote:
> 
> This cannot be done in Lua 5.1 since 'os.time()' only calls for  
> 'mktime()', never 'timegm'.  These two are a pair, and described  
> together on the man pages (man mktime). mktime is for creating epoch  
> ticks out of local time; timegm is for doing the same from UTC time.
> 
> Is there a reason for the omission, and could 'os.time()' support UTC  
> input in the future?

I don't know about the system you refer to (Darwin?), but 'man mktime'
on the system I'm currently at opens the ctime(3) manpage which only
lists mktime() in the synopsis and has a timegm(3) xref in the SEE ALSO
section.  The (separate) timegm(3) manpage states:

| ...
| 
| CONFORMING TO
| 
|   These functions are non-standard GNU extensions that are also
|   present on the BSDs.  Avoid their use; see NOTES.
| 
| NOTES
| 
| ...
| 
|   For a portable version of timegm(), set the TZ environment
|   variable  to  UTC,  call mktime(3) and restore the value of
|   TZ.  Something like
| 
| ...

Looking up the www.freebsd.org -> documentation -> manpages -> "timegm"
search text brings up the ctime(3) manpage, where the STANDARDS section
states:

|   The timegm() function is not specified by any standard; its function
|   cannot be completely emulated using the standard functions described
|   above.

This is what Klaus cited, too, IIUC.


So it seems the timegm(3) function may or may not be present, and since
it's not ANSI it certainly won't be used in stock Lua.  If support for
your request would be introduced, it either had to use the workaround
mentioned in the Linux manpage (modify TZ and restore it after calling
mktime(), which seems ugly and might introduce new problems depending on
how environment variables and e.g. OS threads interact) or be an option
which is off by default (to get enabled by the user on systems where
timegm() is known to exist and work correctly).

Would an alternative approach be to determine the difference between the
local and the UTC coordinates and apply that offset to the ticks value
before calling the actual conversion or breaking down?  Could that solve
your problem as well, and do so faster?


virtually yours
Gerhard Sittig
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.