home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / 7811 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  3.2 KB
  1. Xref: sparky comp.databases:7811 comp.databases.ingres:1874
  2. Newsgroups: comp.databases,comp.databases.ingres
  3. Path: sparky!uunet!stanford.edu!ames!nsisrv!stars.gsfc.nasa.gov!thompson
  4. From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
  5. Subject: Re: Dateformat in 6.4
  6. Message-ID: <12NOV199220570715@stars.gsfc.nasa.gov>
  7. News-Software: VAX/VMS VNEWS 1.4-b1  
  8. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  9. Nntp-Posting-Host: stars.gsfc.nasa.gov
  10. Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
  11. References: <1992Nov5.175319.10856@hsr.no> <1992Nov12.133356.7615@tpghq.com>
  12. Distribution: usa
  13. Date: Fri, 13 Nov 1992 00:57:00 GMT
  14. Lines: 64
  15.  
  16. In article <1992Nov12.133356.7615@tpghq.com>, sfc@tpghq.com (Steve Caswell) writes...
  17. >In article <1992Nov5.175319.10856@hsr.no> liland@hsr.no (Trygve Liland) writes:
  18. >>
  19. >>
  20. >>I have a problem with the date datatype in Ingres. I use Embedded SQL from
  21. >>my C program. Input to the database is OK, so is the data in the database, 
  22. >>but when it comes to output from the db and into my C variable I have a problem.
  23. >>
  24. >>I have tried to get the date as date_gmt, but it comes out 6 hours wrong, and
  25. >>that is not only in my C program but also in ISQL. My platform is HP 730,
  26. >>HP-UX 8.05. (That is 6 hours wrong GMT)
  27. >>
  28. >>Is there a way to get the date, just as it is in the db ?? I have tried most 
  29. >>off the possibillities in the manual, but it still doesn't comes out rigth.
  30. >>Is it a familiar problem ?, AND is there a solution to it ??
  31.  
  32.     (stuff deleted)
  33.  
  34. >The following information may help.  This is an Expert Note from the INGRES
  35. >Advisor explaining a problem INGRES has in returning dates that were input
  36. >during daylight savings time.
  37.  
  38.     (stuff deleted)
  39.  
  40. >     The bug appears when Ingres retrieves  a  date  during  DST  that  was
  41. >entered  during  Standard  time  (or vice versa).  Using the above example,
  42. >let's assume '11-apr-91 12:00:00' was entered during Standard time.  There-
  43. >fore,  it  was  stored in the database as '11-apr-91 20:00:00'.  Now, let's
  44. >say we try to retrieve that date during DST.  Once the backend fetches  the
  45. >date,  the  frontend  will  convert  it  by first subtracting the number of
  46. >minutes west of GMT, giving '11-apr-91 12:00:00'.  It then checks to see if
  47. >DST is currently in effect and finds that it is.  Therefore, it adds 1 hour
  48. >to the time, giving '11-apr-91 13:00:00'.  This is not the  time  that  was
  49. > 
  50. > 
  51. > 
  52. >                              April 11, 1991
  53. > 
  54. > 
  55. > 
  56. > 
  57. > 
  58. >                                   - 2 -
  59. > 
  60. > 
  61. >originally entered and this, therefore, is the bug.
  62. > 
  63. > 
  64. >2.  Workaround
  65. > 
  66. >     The workaround is platform specific, but it involves  instructing  the
  67. >operating  system  to  not  automatically  update the system clock when DST
  68. >begins or ends.  This will guarantee  that  Ingres  always  does  the  same
  69. >conversion  for  any date that it has stored.  The disadvantage is that the
  70. >system administrator will have to manually update the system clock twice  a
  71. >year instead of having this done automatically by Unix.  This seems a small
  72. >price to pay compared to the advantages of having a consistent database.
  73.  
  74. Or, one could ask Ingres to get it right in the first place.
  75.  
  76. Does this bug also appear in other major database, e.g. Informix, Oracle,
  77. Sybase, etc.
  78.  
  79. Bill Thompson
  80.