Misunderstanding/issues or even bug in timDate

[David Winsemius]

On Sep 26, 2011, at 11:56 AM, Martin Maechler wrote:

>>>>>> Samo Pahor <samo.pahor at gmail.com>
>>>>>>    on Sat, 24 Sep 2011 11:10:50 +0200 writes:
>
>> Hello authors of great rmetrics package, I use your
>> packages on a daily basis supporting my market
>> analysis. Thank you for all your efforts
>> developing/maintaining them.
>
>> I have encountered some issues (or I may not be understanding the
>> design) while using dateTime package. I have ask a question about the
>> issue here
>> http://stackoverflow.com/questions/7525226/find-whether-a-particular-date-is-an-option-expiration-friday-problem-with-timeand
>
> We are typically not reading that...
>
>> user DWin researched a bit and send you a report on the issue.
>
> Yes, though it was not reproducible:
> The crucial part is timezone-dependent !
>
>> If this is a bug, can I in anyway help/assist you in order
>> to get the patch for the package on r-forge as soon as
>> possible? I am desperately dependent on correct
>> functioning of particular functions in very useful
>> timeDate.
>
> I have now committed patches to the R-forge version of
> 'timeDate',
> 	as revision 5121

Looking first at the bug report page (where I had been expecting to  
see some version of my Friday report, but only because I don't really  
understand the system)  and then looking at the new revision, it  
appears that the fix proposed in July to this code has not been  
accepted:

## On or after:
  lt1 <- lt
  lt1$mday <- 1
  ct <- 24*3600*(as.integer(julian.POSIXt(lt)) + (nth-1)*7 + (nday- 
lt1$wday)%%7)
# ==== It was suggested that it should be:
  lt1 <- lt
lt1$mday = 1
  ct = 24 * 3600 * (as.integer(julian.POSIXt(lt1)) + (nth - 1) * 7 +  
(nday - lt1$wday)%%7)

> {this is *not* yet visible on R-forge; you need to wait a few
> hours, and for the binary Windows or Mac package, probably even a day
> or two ...}
>
> Best regards,
> Martin Maechler, ETH Zurich

David Winsemius, MD
West Hartford, CT