[R] RODBC & POSIX & Daylight Saving blues

[Gabor Grothendieck]

Prof Brian Ripley <ripley <at> stats.ox.ac.uk> writes:

: 
: On Thu, 11 Nov 2004, Bernie McConnell wrote:
: 
: > Dear All,
: >
: > The recent improvement in RODBC to recognize datetimes in tables has
: > exposed my ongoing confusion.
: >
: > All my data are obtained from a satellite system (Argos) which tags events
: > in the GMT time zone.  Daylight saving is ignored.  To my way of thinking
: > this means that
: >
: >    1.  twelve-o-clock means halfway through the day regardless of season, 
and
: >    2.  the difftime of any two dates where the time is set to
: > twelve-o-clock should be an integer, regardless of which season each of the
: > dates are in.
: >
: > I illustrate my confusion with a two-line table in an Access 2000 database
: > table where the single field called 'theDate' contains the two values:
: >
: > 30/07/04 12:00:00
: > 30/11/04 12:00:00
: >
: > then I bring the datetimes into R with the following code:
: >
: >  > library (RODBC)
: >  > theChannel <- odbcConnect("phonetagcopy", "", "")
: >  > pp <- sqlFetch(theChannel, "DateTest")
: >  > odbcClose(theChannel)
: >  > pp$theDate
: > [1] "2004-07-30 12:00:00 GMT Daylight Time"
: > [2] "2004-11-30 12:00:00 GMT Standard Time"
: >  >
: >  > unclass(pp$theDate) / 86400
: > [1] 12629.46 12752.50
: > attr(,"tzone")
: > [1] ""
: >  >
: >  > difftime (pp$theDate[1], pp$theDate[2])
: > Time difference of -123.0417 days
: >
: > It appears that sqlFetch has (in this case wrongly) assumed that my
: > datetimes are corrected for Daylight Saving.  How can I persuade it to
: > accept that all my datetimes are in straight GMT?
: 
: All date-time conversions in R by default occurs in the current timezone.
: If you set it to GMT for the duration of the sqlFetch call, it should do
: as you intended (but had not told R, which is not clairvoyant).
: 

On Windows you have to set the whole computer to GMT which has
the potential to interfere with other programs so I don't think 
that that can be the final solution.  I believe that on UNIX it
would be better since its per process there but even then
it has the potential to disrupt the current R session.

If the data is stored in a table using a type that does not have
time zones then it should be mapped into a datetime class in R that 
also has no time zones.   It would be safer to convert it to chron
or to create some new datetime class that matches the data's type
or not convert it and leave it to the user.