Re: Date command not returning proper relative time on DST boundary cross over

[Pádraig Brady]

unarchive 11098 18159
forcemerge 11098 18159
stop

On 04/08/15 22:49, Jakub Luzny wrote:
> Hi,
> 
> I would like to fix the issue described here: 
> https://access.redhat.com/solutions/328533
> 
> There is a problem that date is using the tm_isdst settings from the present 
> time got by gettimeofday(). This behavior is wrong when the relative time 
> offset causes transition to/from DST time. 
> 
> The easy fix is to change parse_datetime.y:1342 from
> 
>> tm.tm_isdst = tmp->tm_isdst;
> 
> to
> 
>>   tm.tm_isdst = -1;
> 
> As written in mktime(3): 
>>  negative value means that mktime() should (use timezone information and 
>> system databases to) attempt to determine whether DST is in effect at the 
>> specified time.
> 
> This behavior is maybe not fully correct (why?), because it was removed 
> historically: 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc062ad089529e692add3aee0564a73a0812f212
> and added later for absolute timestamps: 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/getdate.y?id=85a3961efb18c798d6dc2fda46332b22dbd4a955
> 
> I could't find anything about the bug referenced in the first commit.
> 
> The issue can be easily simulated using faketime utility:
> 
> $ LANG=C TZ=EST5EDT faketime  '2013-03-11 0:15:00' /bin/date -d "1 day ago"
> Sat Mar  9 23:15:00 EST 2013
> 
> So, I would like to ask: why is it wrong to use -1 for time_isdst, and why it 
> is correct for absolute timestamps? I tried to get some wrong behaviour after 
> the change, but didn't got any. Maybe I didn't try enough. All tests passed.
> 
> Any tips on how this could be done better are welcome.

For the date command we were thinking of using
a higher level calculation as discussed at: http://bugs.gnu.org/18159#8

Red Hat is tracking that at https://bugzilla.redhat.com/1117519

cheers,
Pádraig.