Daylight Savings Time functioning by date-CodePudding

I am trying to do Daylight Savings Time conversion. I am having difficulties dimensioning "date" in the "void IsDst(date){" I have tried "void IsDst(datetime date){" Not sure how it works?

dstdata.htm

   date = new DateTime(yr, mo-1, dy, hr24, mn, 0);
   Textbox7.value = IsDst(date);

dstdata.js

   private void IsDst(date){
     if (date.month < 2 || date.month > 10){
            return 0; 
     }elseif (date.month >= 2 && month <= 10){ 
          var aaa=0;
          if (date.month==2){
              var dstshr=2;
              for (var dys=1;dys<=25;dys  ){
                  var dsts= new DateTime(yr, 2, dys, dstshr, 0, 0);
                  if ((dsts.DayOfWeek==0) && (aaa==1)){
                      if (date.Date<dsts.Date){
                          return 0;
                      }else{
                          return 1;   
                      }
                  }elseif ((dsts.DayOfWeek==0) && (aaa==0)){              
                      aaa=1;
                      dstshr=3;
                   }
               }
          }
      }elseif(date.month==10){
          var bbb=0;
          var dstehr=2;
          for (var dye=1;dye<=25;dye  ){
              dste= new DateTime(yr, 10, dye, dstehr, 0, 0);
              if ((dste.DayOfWeek==0) && (bbb==0)){
                  dste.hour=dste.hour 1;
                  bbb=1;
                  if ((date.Date<dste.Date){
                      return 0;
                  }else{
                      return 1;   
                  }
              }
         }            
      }
  }elseif (date.month > 2 && month < 10){         
      return 1;
  }

CodePudding user response：

One case of confusion (and problems).

Method IsDst seems to have a void return type, has a name that suggests that it returns a boolean, and returns integer.

CodePudding user response：

The code doesn't appear to be ECMAScript. The logic appears quite convoluted and the block:

} elseif(date.month==10) {

will never be entered because if it's true, it will already be caught by the previous block:

} elseif (date.month >= 2 && month <= 10) {

If you are trying to work out if DST is in force for a particular date based on the host settings, then you can test:

Does the host observe DST?
Is DST in force on the particular date?

E.g.

// Return true if DST is observed in the year of date
function hasDST(date = new Date()) {
  let year = date.getFullYear();
  return !(new Date(year, 0).getTimezoneOffset() == new Date(year, 6).getTimezoneOffset());
}
// Return true if DST is observed for the year of the date and
// the offset on the date is the same as the DST offset for
// that year
function inDST(date = new Date()) {
  let year = date.getFullYear();
  // Offset has opposite sign to convention so use min not max
  let dstOffset = Math.min(
    new Date(year, 0).getTimezoneOffset(),
    new Date(year, 6).getTimezoneOffset(),
  );
  return hasDST(date) && date.getTimezoneOffset() == dstOffset;
}

// Test
let y = new Date().getFullYear();
[new Date(2022,0),  // 1 Jan 2022
 new Date(2022,6),  // 1 Jul 2022
 new Date(2023,0),  // 1 Jan 2023
 new Date(2023,6),  // 1 Jul 2023
 new Date(y   ,0),  // 1 Jan current year
 new Date(y   ,6),  // 1 Jul current year
].forEach(d => console.log(
   `${d.toString()} is in DST? ${inDST(d)}`
));

The above assumes that if the offsets for 1 Jan and 1 Jul are different, then daylight saving is observed in that year and that the minimum of those two offsets is the DST offset (noting that ECMAScript offsets have the opposite sense to convention, i.e. they are ve to the west and -ve to the east of Greenwich). However, the fact that the two offsets are different doesn't necessarily mean DST is observed (see below).

Once implementations are updated for the probable change to permanent DST in the US on 5 Nov 2023:

hasDST will return true for all dates in 2023 and false for all dates thereafter
inDST will return true for all dates from 5 Nov 2023 to 31 Dec 2023
hasDST and inDST will return false for dates after 2023 (i.e. 1 Jan 2024 onward)

So for 5 Nov to 31 Dec 2023 both hasDST and inDST will return true when they should be false. Similar errors will occur for other places that change offsets during the year.

The whole point of both these functions is questionable given whether a date is in DST or not for a particular location really is irrelevant, what matters is the offset. There are many places that don't have DST at all.

Ireland not only doesn't have DST, it has the opposite: its standard time over summer (IST) is UTC 1, then clocks are set back to UTC 0 (GMT) over winter. The above thinks that IST is daylight saving and GMT is standard time.

Hence the reason why it's best to just save dates as dates without a timezone and datetimes as UTC, then work out the offset only as required for a specific place based on offset rules known at the time of conversion.