os.time() vs. isdst

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

os.time() vs. isdst

Alexander Gladysh
Hi, list!

In Lua 5.1 and 5.2 time table `isdst` field is boolean.

But actually, in its C counterpart, `struct tm`, `tm_isdst` it is a
tribool. Quoting `man gmtime` (did not check C89 standard sorry):

`tm_isdst`  A flag that indicates whether daylight saving time is in
effect at the time described.  The value is positive if daylight
saving time is in effect, zero if it is not, and negative if the
information is not available.

Now, I've hit a nasty issue[1] when I *must* use negative `isdst`
value. I do not hope that there is a way to workaround this for stock
`os.date()`, so I have to roll out my own C module for 5.1.

But maybe it is not too late to change this in 5.2?

Alexander.

[1] — http://stackoverflow.com/questions/5559294/dst-switch-aware-getter-for-unix-timestamp-of-current-days-local-time-midnight/5560261#5560261

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Alexander Gladysh
On Wed, Apr 6, 2011 at 05:31, Alexander Gladysh <[hidden email]> wrote:

> Now, I've hit a nasty issue[1] when I *must* use negative `isdst`
> value. I do not hope that there is a way to workaround this for stock
> `os.date()`, so I have to roll out my own C module for 5.1.

> But maybe it is not too late to change this in 5.2?

I'm not sure, but it looks to me that, in order to ensure correct
behavior of gmtime(), os.date() must set tm_isdst to -1 unless user
explicitly specified a value. (And not doing so is probably a bug
worth fixing in 5.1.5.) Maybe someone would shed a light on this?

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Alexander Gladysh
On Wed, Apr 6, 2011 at 05:42, Alexander Gladysh <[hidden email]> wrote:
> On Wed, Apr 6, 2011 at 05:31, Alexander Gladysh <[hidden email]> wrote:

> I'm not sure, but it looks to me that, in order to ensure correct
> behavior of gmtime(), os.date() must set tm_isdst to -1 unless user
> explicitly specified a value. (And not doing so is probably a bug
> worth fixing in 5.1.5.) Maybe someone would shed a light on this?

Oops. Sorry, not `gmtime()`, but, of course, `mktime()`.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Tony Finch
In reply to this post by Alexander Gladysh
Alexander Gladysh <[hidden email]> wrote:
>
> But actually, in its C counterpart, `struct tm`, `tm_isdst` it is a
> tribool. Quoting `man gmtime` (did not check C89 standard sorry):
>
> `tm_isdst`  A flag that indicates whether daylight saving time is in
> effect at the time described.  The value is positive if daylight
> saving time is in effect, zero if it is not, and negative if the
> information is not available.

This is almost a direct quote from the standard.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Fisher: Southwest, veering west later, 5 to 7, perhaps gale 8 later. Moderate
or rough. Occasional rain. Moderate or good, occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Tony Finch
In reply to this post by Alexander Gladysh
Alexander Gladysh <[hidden email]> wrote:
>
> I'm not sure, but it looks to me that, in order to ensure correct
> behavior of gmtime(), os.date() must set tm_isdst to -1 unless user
> explicitly specified a value. (And not doing so is probably a bug
> worth fixing in 5.1.5.) Maybe someone would shed a light on this?

Sounds right to me.

The standard C time library is pretty crappy.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Fisher: Southwest, veering west later, 5 to 7, perhaps gale 8 later. Moderate
or rough. Occasional rain. Moderate or good, occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Luiz Henrique de Figueiredo
In reply to this post by Alexander Gladysh
> But actually, in its C counterpart, `struct tm`, `tm_isdst` it is a
> tribool.
>
> But maybe it is not too late to change this in 5.2?

It's already like that: isdst is not set if tm_isdst is negative.
So tribool means true, false, and nil. :-)

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Alexander Gladysh
On Wed, Apr 6, 2011 at 15:57, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> But actually, in its C counterpart, `struct tm`, `tm_isdst` it is a
>> tribool.

>> But maybe it is not too late to change this in 5.2?

> It's already like that: isdst is not set if tm_isdst is negative.
> So tribool means true, false, and nil. :-)

Yes, you're right.

I should have looked at getboolfield() definition.

Sorry for the noise. :-(

But maybe you can clarify os.date() definition in manual? It is not
obvious that this feature is supported. (Not sure about the wording
though.)

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Roberto Ierusalimschy
> But maybe you can clarify os.date() definition in manual? It is not
> obvious that this feature is supported. (Not sure about the wording
> though.)

 ...
 and 'isdst' (daylight saving flag, a boolean).
+This last field may be absent if the system
+does not have this information.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Alexander Gladysh
On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
<[hidden email]> wrote:
>> But maybe you can clarify os.date() definition in manual? It is not
>> obvious that this feature is supported. (Not sure about the wording
>> though.)

>  ...
>  and 'isdst' (daylight saving flag, a boolean).
> +This last field may be absent if the system
> +does not have this information.

Not sure about the mention of "system" — in os.time() it is user who
does not have the information.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Roberto Ierusalimschy
> On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
> <[hidden email]> wrote:
> >> But maybe you can clarify os.date() definition in manual? It is not
> >> obvious that this feature is supported. (Not sure about the wording
> >> though.)
>
> >  ...
> >  and 'isdst' (daylight saving flag, a boolean).
> > +This last field may be absent if the system
> > +does not have this information.
>
> Not sure about the mention of "system" — in os.time() it is user who
> does not have the information.

We may just copy six words from the ISO standard:

+This last field may be absent
+if the information is not available.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Alexander Gladysh
On Wed, Apr 6, 2011 at 19:31, Roberto Ierusalimschy
<[hidden email]> wrote:
>> On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
>> <[hidden email]> wrote:
>> >> But maybe you can clarify os.date() definition in manual? It is not
>> >> obvious that this feature is supported. (Not sure about the wording
>> >> though.)

>> >  ...
>> >  and 'isdst' (daylight saving flag, a boolean).
>> > +This last field may be absent if the system
>> > +does not have this information.

>> Not sure about the mention of "system" — in os.time() it is user who
>> does not have the information.

> We may just copy six words from the ISO standard:

> +This last field may be absent
> +if the information is not available.

Sounds good to me.

Alexander.

Reply | Threaded
Open this post in threaded view
|

RE: os.time() vs. isdst

Geoff Smith
In reply to this post by Roberto Ierusalimschy
Hi
 
While we are on the subject of os.date os.time etc. Can someone volunteer to check this for me please ?
 
PiL chapter 22 states
 
temp = os.date("*t", 906000490)
produces the table

    {year = 1998, month = 9, day = 16, yday = 259, wday = 4,
     hour = 23, min = 48, sec = 10, isdst = false}
 
 
Is 906000490 the correct number here ? I cant get it to give me the table numbers stated below it ?
 
It could be me misunderstanding something, or is it a mistake ?
 
Regards Geoff
 
PS Do I win a prize for spotting a 13 year old mistake ? :)
 
 
 
> Date: Wed, 6 Apr 2011 12:31:16 -0300

> From: [hidden email]
> To: [hidden email]
> Subject: Re: os.time() vs. isdst
>
> > On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
> > <[hidden email]> wrote:
> > >> But maybe you can clarify os.date() definition in manual? It is not
> > >> obvious that this feature is supported. (Not sure about the wording
> > >> though.)
> >
> > >  ...
> > >  and 'isdst' (daylight saving flag, a boolean).
> > > +This last field may be absent if the system
> > > +does not have this information.
> >
> > Not sure about the mention of "system" — in os.time() it is user who
> > does not have the information.
>
> We may just copy six words from the ISO standard:
>
> +This last field may be absent
> +if the information is not available.
>
> -- Roberto
>
Reply | Threaded
Open this post in threaded view
|

RE: os.time() vs. isdst

Norbert Kiesel
On Wed, 2011-04-06 at 20:57 +0100, Jeff Smith wrote:

> While we are on the subject of os.date os.time etc. Can someone
> volunteer to check this for me please ?
>  
> PiL chapter 22 states
>  
> temp = os.date("*t", 906000490)
> produces the table
> {year = 1998, month = 9, day = 16, yday = 259, wday = 4,
>      hour = 23, min = 48, sec = 10, isdst = false}
>  
>  
> Is 906000490 the correct number here ? I cant get it to give me the
> table numbers stated below it ?

I get these numbers with
% TZ=UTC+3 lua -e 'for k,v in pairs(os.date("*t", 906000490)) do
print(k,v) end'

>  
> It could be me misunderstanding something, or is it a mistake ?
>  
> Regards Geoff
>  
> PS Do I win a prize for spotting a 13 year old mistake ? :)

I'm afraid you have to try a bit harder :-)

</nk>



Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Louis Mamakos
In reply to this post by Geoff Smith
<base href="x-msg://481/">
Time zone and daylight savings time difference for you?  When I try the example, I get differences in the hour and isdst fields.

$  lua -e 't = os.date("*t", 906000490);print(t.hour,t.min,t.sec,t.isdst)'
22 48 10 true

However, I use use a different timezone, it seems to be correct:

$ TZ=Brazil/East lua -e 't = os.date("*t", 906000490);print(t.hour,t.min,t.sec,t.isdst)'
23 48 10 false


On Apr 6, 2011, at 3:57 PM, Jeff Smith wrote:

Hi
 
While we are on the subject of os.date os.time etc. Can someone volunteer to check this for me please ?
 
PiL chapter 22 states
 
temp = os.date("*t", 906000490)
produces the table 

    {year = 1998, month = 9, day = 16, yday = 259, wday = 4,
     hour = 23, min = 48, sec = 10, isdst = false}
 
 
Is 906000490 the correct number here ? I cant get it to give me the table numbers stated below it ?
 
It could be me misunderstanding something, or is it a mistake ?
 
Regards Geoff
 
PS Do I win a prize for spotting a 13 year old mistake ? :)
 
 
 

> Date: Wed, 6 Apr 2011 12:31:16 -0300
> From: [hidden email]
> To: [hidden email]
> Subject: Re: os.time() vs. isdst
> 
> > On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
> > <[hidden email]> wrote:
> > >> But maybe you can clarify os.date() definition in manual? It is not
> > >> obvious that this feature is supported. (Not sure about the wording
> > >> though.)
> > 
> > >  ...
> > >  and 'isdst' (daylight saving flag, a boolean).
> > > +This last field may be absent if the system
> > > +does not have this information.
> > 
> > Not sure about the mention of "system" — in os.time() it is user who
> > does not have the information.
> 
> We may just copy six words from the ISO standard:
> 
> +This last field may be absent 
> +if the information is not available.
> 
> -- Roberto
> 

Reply | Threaded
Open this post in threaded view
|

RE: os.time() vs. isdst

Geoff Smith
Thanks for the clarification guys, yes thats the explanation, the discrepancy is the timezone difference of 3 hours (I am in the UK)
 
I  maintain that is a pretty horrid example for a newbie reading that os.date page, as there is no mention of time zone dependancy at that point. Not totally suprisingly it didnt occur to me you have to be typing away at a PC in Brazil for the numbers to work out correctly !
 
Thats another prize I havent won then :)
 
Regards Geoff
 
 

From: [hidden email]
Date: Wed, 6 Apr 2011 17:09:18 -0400
To: [hidden email]
Subject: Re: os.time() vs. isdst

Time zone and daylight savings time difference for you?  When I try the example, I get differences in the hour and isdst fields.

$  lua -e 't = os.date("*t", 906000490);print(t.hour,t.min,t.sec,t.isdst)'
22 48 10 true

However, I use use a different timezone, it seems to be correct:

$ TZ=Brazil/East lua -e 't = os.date("*t", 906000490);print(t.hour,t.min,t.sec,t.isdst)'
23 48 10 false


On Apr 6, 2011, at 3:57 PM, Jeff Smith wrote:

Hi
 
While we are on the subject of os.date os.time etc. Can someone volunteer to check this for me please ?
 
PiL chapter 22 states
 
temp = os.date("*t", 906000490)
produces the table 

    {year = 1998, month = 9, day = 16, yday = 259, wday = 4,
     hour = 23, min = 48, sec = 10, isdst = false}
 
 
Is 906000490 the correct number here ? I cant get it to give me the table numbers stated below it ?
 
It could be me misunderstanding something, or is it a mistake ?
 
Regards Geoff
 
PS Do I win a prize for spotting a 13 year old mistake ? :)
 
 
 

> Date: Wed, 6 Apr 2011 12:31:16 -0300
> From: [hidden email]
> To: [hidden email]
> Subject: Re: os.time() vs. isdst
> 
> > On Wed, Apr 6, 2011 at 17:39, Roberto Ierusalimschy
> > <[hidden email]> wrote:
> > >> But maybe you can clarify os.date() definition in manual? It is not
> > >> obvious that this feature is supported. (Not sure about the wording
> > >> though.)
> > 
> > >  ...
> > >  and 'isdst' (daylight saving flag, a boolean).
> > > +This last field may be absent if the system
> > > +does not have this information.
> > 
> > Not sure about the mention of "system" — in os.time() it is user who
> > does not have the information.
> 
> We may just copy six words from the ISO standard:
> 
> +This last field may be absent 
> +if the information is not available.
> 
> -- Roberto
> 

Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Roberto Ierusalimschy
> I maintain that is a pretty horrid example for a newbie reading that
> os.date page, as there is no mention of time zone dependancy at that
> point.

I am not sure what I call "at that point", but there is a clear mention
a couple of paragraphs before:

  In a Unix system (where the epoch is 00:00:00 UTC, January 1, 1970)
  running in Rio de Janeiro (which is three hours west of Greenwich), we
  have the following examples:

It seems reasonable to assume that the author did not move to another
country between the two examples.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: os.time() vs. isdst

Geoff Smith
Hi
 
> In a Unix system (where the epoch is 00:00:00 UTC, January 1, 1970)
> running in Rio de Janeiro (which is three hours west of Greenwich), we
> have the following examples:

> It seems reasonable to assume that the author did not move to another
> country between the two examples.

:)
 
Thanks for updating that page so swiftly then Roberto, I am sure that paragraph wasnt there the
first time I read it tonight. Cough Cough !!
 
Regards Geoff
 
P.S Many thanks for coming up with such an interesting and powerful programming language, I am enjoying learning it.
 
 
 

 
> Date: Wed, 6 Apr 2011 20:35:39 -0300

> From: [hidden email]
> To: [hidden email]
> Subject: Re: os.time() vs. isdst
>
> > I maintain that is a pretty horrid example for a newbie reading that
> > os.date page, as there is no mention of time zone dependancy at that
> > point.
>
> I am not sure what I call "at that point", but there is a clear mention
> a couple of paragraphs before:
>
> In a Unix system (where the epoch is 00:00:00 UTC, January 1, 1970)
> running in Rio de Janeiro (which is three hours west of Greenwich), we
> have the following examples:
>
> It seems reasonable to assume that the author did not move to another
> country between the two examples.
>
> -- Roberto
>
Reply | Threaded
Open this post in threaded view
|

Re: os.time() vs. isdst

Dirk Laurie
On Thu, Apr 07, 2011 at 01:52:52AM +0200, Jeff Smith wrote:

> Hi
>
> > In a Unix system (where the epoch is 00:00:00 UTC, January 1, 1970)
> > running in Rio de Janeiro (which is three hours west of Greenwich), we
> > have the following examples:
>
> > It seems reasonable to assume that the author did not move to another
> > country between the two examples.
>
> :)
>
> Thanks for updating that page so swiftly then Roberto, I am sure that
> paragraph wasnt there the first time I read it tonight. Cough Cough !!

Have you checked your duly purchased paper copy of PiL2?

Dirk