发送到谷歌应用脚本的谷歌电子表格对象包装器中是否存在错误

Is there a bug in Google Spreadsheet object wrapper sent to Google Apps Script?

本文关键字:谷歌 包装 是否 存在 对象 错误 电子表格 应用 脚本      更新时间:2023-09-26

附上一张测试表,显示结果和预期结果。测试工作表具有运行工作表所需的所有功能。

main 函数应该返回从开始日期生成的一系列日期。每个日期应比其前一个日期早三个月。

该测试使用两个版本的函数,一个版本对日期对象使用 UTC 日期方法,另一个对日期对象使用普通日期方法。

"工作簿"中名为 quarter 的工作表具有结果。工作表处理测试依赖于以下命名范围:StartDateQ,StartDateWeird

任何试图解决这个问题的人只需要查看名为 quarter 的工作表,包含函数的脚本页面,并具有 Google Apps 脚本和 Google 电子表格 API 的工作知识。

问题所在

返回日期的数组与预期不符。在某些情况下,日期看起来正确,但某些日期具有不需要的时间数据,只能通过选择单元格来查看。在某些情况下,日期不正确,相差一天。

为什么这是一个问题?

在实际电子表格中,依赖于日期匹配的公式失败,因为某些可视日期具有关联的实际时间数据。由于时间数据不匹配,即使从视觉上看,日期看起来相同,匹配也会失败。匹配失败会中断工作表。

算法

  1. 如果至少有一个要处理的开始日期,请使用 countAge() 获取生成日期的季度数。
  2. 使用电子表格发送的开始日期初始化日期对象。
  3. 创建一个空数组来保存要返回电子表格的日期。
  4. 对于季度计数,一次循环一个计数。
  5. 最新日期插入数组。
  6. 将日期移至下一个季度,直到没有更多要生成日期的季度。
  7. 将结果返回到电子表格

使用中的函数(内部 API)

is(obj, type)//compare object 是否是正确的类型

countAge(dateString,dateString2)//count dates 之间的年份,又名 age

测试版本

季度UTC(开始日期,结束日期)//自定义函数从两个日期获取季度日期 — UTC 版本

季度普通(开始日期,结束日期)//自定义函数从两个日期获取季度日期 — 普通版

评论

由于这两个测试函数都不依赖于"日期数学",而是依赖于日期设置器,例如,

不是这个:

d = new Date(); d.setMonth(d.getMonth()) + 3;

但是这个: if (latestDate.getMonth() == 0) { latestDate.setMonth(3,1) }

编程逻辑无法产生预期结果的原因似乎并不明显。

函数

这是普通版本。UTC 版本使用 .setUTCmonth()

function quartersPlain(startDate,endDate)  {
// Check if there is a date to process, if not, exit.
  if (!is(startDate,"Date")) {
      return "Missing date";
  }

// Let's get the number of quarters  

  /* If there isn't an end date, we want the tally from the start date to now, aka the true age
     otherwise, we want want the tally between two dates.
  */
  var tally = 0; 
  if (!is(endDate,"Date")) {
    tally = (countAge(startDate) * 4) + 3
  } 
  else {
    if (new Date(endDate) > new Date(startDate)) {
      tally = (countAge(startDate,endDate) * 4)
    }
    else {
      tally = (countAge(endDate,startDate) * 4)
      startDate = endDate
    }
  }
  // testing ...
  // return tally

/* 
1. Initialize date object with start date sent from spreadsheet.
2. Make an empty array to hold dates to return to the spreadsheet.
3. For the tally of quarters, loop through one count at a time.
4. Insert the latest date to the array.
5. Move the date along to the next quarter.
*/
  // it's a logical fail needing to assign the date twice, kludgy 
  var latestDate = new Date(startDate);
  /* testing ...
  latestDate.setFullYear(latestDate.getUTCFullYear());
  latestDate.setUTCMonth(latestDate.getUTCMonth());
  latestDate.setDate(latestDate.getUTCDate());  
  */
  var dates = [ ]; 
  for (var loop = 0; loop < tally; loop++) {
    dates.push(new Date(latestDate));

    if (latestDate.getMonth() == 0) {
        latestDate.setMonth(3,1)
    }
    else if (latestDate.getMonth() == 1) {
        latestDate.setMonth(4,1)
    }
    else if (latestDate.getMonth() == 2) {
        latestDate.setMonth(5,1)
    }    
    else if (latestDate.getMonth() == 3) {
        latestDate.setMonth(6,1)
    }    
    else if (latestDate.getMonth() == 4) {
        latestDate.setMonth(7,1)
    }    
    else if (latestDate.getMonth() == 5) {
        latestDate.setMonth(8,1)
    }    
    else if (latestDate.getMonth() == 6) {
        latestDate.setMonth(9,1)
    }    
    else if (latestDate.getMonth() == 7) {
        latestDate.setMonth(10,1)
    }    
    else if (latestDate.getMonth() == 8) {
        latestDate.setMonth(11,1)
    }    
    else if (latestDate.getMonth() == 9) {
        latestDate.setMonth(0,1)
        latestDate.setFullYear(latestDate.getFullYear() + 1)
    }    
    else if (latestDate.getMonth() == 10) {
        latestDate.setMonth(1,1)
        latestDate.setFullYear(latestDate.getFullYear() + 1)
    } 
    else if (latestDate.getMonth() == 11) {
        latestDate.setMonth(2,1)
        latestDate.setFullYear(latestDate.getFullYear() + 1)
    }           
  }
   return dates;
}

'

简短的回答是这是由于夏令时。

夏季季度的开始时间在使用夏令时的时区中,比没有夏令时生效的日期在物理上早一小时。

因此,例如,在我的时区 (AEST) [澳大利亚 = GMT+10/GMT+11 夏令时] 当我查看您的"开始季度"日期 1-APR-1947(自 1/1/900 以来的 17258 天)时,它会在脚本调试器中将其报告为:

Tue Apr 01 1947 18:00:00 GMT+1000 (AEST)

(顺便说一句,这表明您当地的时区是GMT-8或美国西海岸,是吗?

但是,如果我将其指向夏令时期间的某个日期(例如内部 1/1/1960 - 21916),它报告为:

Fri Jan 01 1960 19:00:00 GMT+1100 (AEDT)

这意味着当你使用.setMonth()或.setUTCMonth()计算函数中的新日期时,这些是"聪明的",并考虑到夏令时。 所以有时在你的结果集中,你会得到一天的额外 .04167(.04167 x 86400 秒 = 3600 秒或 1 小时)。通过将日期列的格式调整为"日期时间",可以很容易地看到

真正的电子表格中,这个问题的简单解决方案是使用 =INT() 只报告 DATE 组件,而无需任何时间......毕竟,这似乎是您真正感兴趣的。

或者,除了 .setMonth() 调用之外,您还可以在脚本函数中使用 .setHours(0)。

我无法在您的示例数据中看到任何"日期相差 1 天",但我可以通过使用 UTC 时间导致类似的结果,然后当它们以本地时区显示时,我可以看到例如 12/31/1949 23:00:00.. 因为在英国冬季澳大利亚有夏天并且处于夏令时,反之亦然 在英国夏季/澳大利亚冬季, 在两者之间(春季和秋季),当两者都没有夏令时时,季度开始日期没有时间成分...... 产生一些有趣的结果:

10/1/1950 0:00:00 12/31/1950 23:00:00 4/1/1951 0:00:00 7/1/1951 1:00:00 10/1/1951 0:00:00

在您的数据中,您还会注意到 1 月/4 月没有时间,7 月/10 月是 +1 的模式在 2007 年发生了变化,当时夏令时略有延长。其他有趣(明显)的异常是因为它们过去玩弄夏令时的方式。

顺便说一下,如果你想让你的原始代码更紧凑,你可以做如下的事情:

for (var loop = 0; loop < tally; loop++) {
    dates.push(new Date(latestDate));
    var nextMonth = (latestDate.getMonth() + 3) % 12;   // mod 12 
    latestDate.setMonth(nextMonth,1);
    if (nextMonth < 3) {
        latestDate.setFullYear(latestDate.getFullYear() + 1)
    }
 }

哦,最后一件事,我建议您将问题的标题更改为"在Google表格/脚本中使用.setMonth()或.setUTCMonth()函数的意外时间结果",因为这可以更好地描述IMO的问题。

干杯。