Re: Does os.time change with dst OR Confused about os.time and os.date

[William Ahern <william@...>]

On Mon, Aug 05, 2013 at 05:55:11PM -0500, Andrew Starks wrote:
> On Monday, August 5, 2013, Andrew Starks wrote:
<snip>
> > The reason that I'm asking this dumb question is that I am confused by
> > the following:
> >
> > > =os.time() - os.time(os.date("*t"))
> > 0
> > > =os.time() - os.time(os.date("!*t"))
> > -21600
<snip>
> I'm responding to my own post, with what I hope is the answer.
> 
> os.date can receive a number value, which is inturpreted in the the same
> way as os.time's output is defined. It returns *local time*. os.time
> follows the standard posix definition, which is usually as described above
> bit it receives a time structure, then it is interpreted as *local time*
> and is converted to UTC number of seconds.
> 
> If time is output from os.date as UTC, then read by os.time, it will be
> converted by os.time and thus be offset by the time zone.
> 
> What's more, if os.time receives the current time in UTC, it shifts it, but
> with isdt as false. If it then receives the current time in the current
> time zone, it shifts it as well, arriving at UTC. do the math and your
> always going to get the non-dst answer.
> 

Yep. There's just no way to round-trip a UTC time like

	 time_t -> struct tm -> time_t

without resetting the timezone locale using setenv and tzset, neither of
which Lua supports because they're POSIX, not standard C. Basically, neither
C nor POSIX define a timezone member for struct tm, and even on systems that
do define one it's usually ignored by mktime().

Solutions like timegm() (which mirrors gmtime()) aren't even defined by
POSIX and are totally non-portable except across open source BSD and GNU
systems.

You can trivially implement a POSIX-portable timegm() thanks to POSIX's
definition of precisely 86400s/day, at least for positive time_t values,
which are the only ones that POSIX technically allows anyhow.

The situation is rather ridiculous. timegm() should be standardized by both
C and POSIX. It's not an ideal interface, but at least consistent with the
existing ones. Unfortunately, Microsoft has abandoned both C and
POSIX--freezing their support to mid-1990s standards), so even if those
standards were updated to support timegm it's unlikely Lua wouldn't be able
to reflect the change.