read-excel-file 9.3.4 → 9.3.5

package/modules/xlsx/parseExcelDate.js

@@ -1,3 +1,5 @@
+import parseExcelTimestamp from './parseExcelTimestamp.js';
+
 // Parses an Excel Date (represented by a "serial" floating-point number)
 // into a javascript `Date` in UTC+0 timezone (with time is set to 00:00).
 //
@@ -5,129 +7,7 @@
 // "If you need to calculate dates in your spreadsheets,
 //  Excel uses its own unique system, which it calls Serial Numbers".
 //
-export default function parseExcelDate(excelSerialDate, options) {
-  // Windows operating system uses floating-point numbers to represent dates,
-  // where the number represents the count of days elapsed since January 0th, 1900.
-  //
-  // This also means that there're 2 aspects associated with this choice:
-  //
-  // * January 1st, 1900, 00:00 is represented by `1` rather than `0`, which looks a bit weird.
-  // * 1900 is a special year because it's a "one in a 100 years" occasion when it's not a leap year.
-  //
-  // To work around those two aspects, Mac OS chose another baseline — January 1st, 1900.
-  // Although, that only postponed the second issue because 2100 is going to be the next "speciaL" year
-  // which is not going to be a "leap" one.
-  //
-  // Older versions of Excel on Mac OS used year 1904 as the default baseline for numeric dates.
-  // Since 2011, Microsoft Excel on Mac OS uses year 1900 as the default baseline for cross-platform consistency.
-  // https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487
-  //
-  // So the 1904 baseline is now deprecated, although still available to be configured manually.
-  // So it still might be encountered in Excel files created on MacOS.
-  // In that case, the Excel file contains a special flag — `<workbook><workbookPr date1904="1"/>...` —
-  // that tells the application which baseline is being used for numeric date timestamps.
-  //
-  if (options && options.epoch1904) {
-    // Convert the numeric date timestamp from 1904 baseline to 1900 baseline.
-    excelSerialDate += (1904 - 1900) * DAYS_IN_YEAR + JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY;
-  }
-  var daysBeforeUnixEpoch = JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY + (1970 - 1900) * DAYS_IN_YEAR + NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970;
-  return new Date(Math.floor((excelSerialDate - daysBeforeUnixEpoch) * DAY));
+export default function parseExcelDate(excelSerialDate, epoch1904) {
+  return new Date(parseExcelTimestamp(excelSerialDate, epoch1904));
 }
-
-// "Excel serial date" is just a (fractional) count of days passed since `00/01/1900`.
-//
-// In contrast, "Unix timestamps" use `01/01/1970` as the baseline for numeric dates.
-//
-// In order to convert one into another, it should calculate the count of days elapsed
-// since `00/01/1900` (Excel epoch) till `01/01/1970` (Unix epoch), or the count of days
-// between year `1900` and year `1970`, plus one day.
-//
-// It also should account for the number of "leap years" between year `1900` and year `1970`,
-// which is 17 of them. https://kalender-365.de/leap-years.php
-//
-// "One year has the length of 365 days, 5 hours, 48 minutes and 45 seconds.
-//  These are 365.2421875 days. This is hard to calculate with, so for practical reasons
-//  a normal year has been given 365 days and a leap year 366 days. In leap years,
-//  February 29th is added as leap day, which doesn't exist in a normal year.
-//  A leap year is every 4 years, but not every 100 years, then again every 400 years.
-//  So the year 1900 wasn't a leap year, but 2000 was".
-//
-// And also, Excel has a historical bug when it incorrectly assumes year `1900` to be a leap year,
-// and, as a result, all Excel serial dates starting from March 1st, 1900 lag 1 day behind
-// and require an additional 1 day to be added to them in order to be converted to a proper timestamp.
-//
-// https://learn.microsoft.com/en-us/answers/questions/5249322/why-does-microsoft-excel-considers-29-02-1900-to-b?forum=msoffice-all&referrer=answers#:~:text=This%20made%20it%20easier%20for,other%20programs%20that%20use%20dates.
-//
-// "When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year,
-//  even though it actually was not a leap year. This made it easier for the program to handle
-//  leap years and caused no harm to almost all date calculations in Lotus 1-2-3.
-//
-//  When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900
-//  was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use
-//  the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3.
-//  Treating 1900 as a leap year also made it easier for users to move worksheets from one program
-//  to the other".
-//
-// So the historical bug is basically that Excel thinks that February 29th, 1900 existed
-// while in reality it didn't. That's why it's actually 1 day off for any date after that one.
-//
-var NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970 = 17;
-var JANUARY_0TH_1900_DAY = 1;
-var ERRONEOUS_FEBRUARY_29_1990_DAY = 1;
-
-// An approximate count of seconds in a day is:
-// 24 hours * 60 minutes in an hour * 60 seconds in a minute
-//
-// It is approximate because a minute could be longer than 60 seconds, due to "leap seconds".
-//
-// Still, javascript `Date`, and UNIX time in general, intentionally
-// drop the concept of "leap seconds" in order to make things simpler.
-// So this approximation is valid and doesn't result in any bugs.
-// https://stackoverflow.com/questions/53019726/where-are-the-leap-seconds-in-javascript
-//
-// "The JavaScript Date object specifically adheres to the concept of Unix Time
-//  (albeit with higher precision). This is part of the POSIX specification,
-//  and thus is sometimes called "POSIX Time". It does not count leap seconds,
-//  but rather assumes every day had exactly 86,400 seconds. You can read about
-//  this in section 20.3.1.1 of the current ECMAScript specification, which states:
-//
-//  "Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.
-//   In time values leap seconds are ignored. It is assumed that there are exactly
-//   86,400,000 milliseconds per day."
-//
-// The reason is that the unpredictable nature of leap seconds makes them very
-// difficult to work with in APIs. One can't generally pass timestamps around
-// that need leap seconds tables to be interpreted correctly, and expect that
-// one system will interpret them the same as another. For example, a timestamp
-// `1483228826` that accounts for "leap seconds" should've been interpreted as
-// "2017-01-01T00:00:00Z", but if the receiver doesn't account for "leap seconds",
-// they would interpret it as "2017-01-01T00:00:26Z" (e.g. POSIX-based systems like Linux),
-// So "leap seconds" aren't really portable.
-// Even on systems that have full frequently-updated "leap second" tables,
-// there's no telling what adjustments those tables will contain in the future
-// (i.e. beyond the 6-month IERS announcement period) because "leap seconds" can't be
-// determined by a fixed mathematical formula or something like that. Instead,
-// scientists introduce them as needed based on the observed Earth's rotation around the sun.
-//
-// "Because the Earth's rotational speed varies in response to climatic and geological events,
-//  UTC leap seconds are irregularly spaced and not precisely predictable. The decision to insert
-// a leap second is made by the International Earth Rotation and Reference Systems Service (IERS),
-// typically about six months in advance, to ensure that the difference between UTC and UT1
-// does not exceed ±0.9 seconds."
-//
-// One example is year `1900` which is "every fourth year" but it still is not a "leap year".
-//
-// To reiterate: to support leap seconds in a programming language, the implementation
-// must go out of its way to do so, and must make tradeoffs that are not always acceptable.
-// Though there are exceptions, the general position is to not support them - not because
-// of any subversion or active countermeasures, but because supporting them properly is much,
-// much harder.
-//
-// https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
-// https://en.wikipedia.org/wiki/Leap_year
-// https://en.wikipedia.org/wiki/Leap_second
-//
-var DAY = 24 * 60 * 60 * 1000;
-var DAYS_IN_YEAR = 365;
 //# sourceMappingURL=parseExcelDate.js.map

package/modules/xlsx/parseExcelDate.js.map

@@ -1 +1 @@
-{"version":3,"file":"parseExcelDate.js","names":["parseExcelDate","excelSerialDate","options","epoch1904","DAYS_IN_YEAR","JANUARY_0TH_1900_DAY","ERRONEOUS_FEBRUARY_29_1990_DAY","daysBeforeUnixEpoch","NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970","Date","Math","floor","DAY"],"sources":["../../source/xlsx/parseExcelDate.js"],"sourcesContent":["// Parses an Excel Date (represented by a \"serial\" floating-point number)\r\n// into a javascript `Date` in UTC+0 timezone (with time is set to 00:00).\r\n//\r\n// https://www.pcworld.com/article/3063622/software/mastering-excel-date-time-serial-numbers-networkdays-datevalue-and-more.html\r\n// \"If you need to calculate dates in your spreadsheets,\r\n//  Excel uses its own unique system, which it calls Serial Numbers\".\r\n//\r\nexport default function parseExcelDate(excelSerialDate, options) {\r\n  // Windows operating system uses floating-point numbers to represent dates,\r\n  // where the number represents the count of days elapsed since January 0th, 1900.\r\n  //\r\n  // This also means that there're 2 aspects associated with this choice:\r\n  //\r\n  // * January 1st, 1900, 00:00 is represented by `1` rather than `0`, which looks a bit weird.\r\n  // * 1900 is a special year because it's a \"one in a 100 years\" occasion when it's not a leap year.\r\n  //\r\n  // To work around those two aspects, Mac OS chose another baseline — January 1st, 1900.\r\n  // Although, that only postponed the second issue because 2100 is going to be the next \"speciaL\" year\r\n  // which is not going to be a \"leap\" one.\r\n  //\r\n  // Older versions of Excel on Mac OS used year 1904 as the default baseline for numeric dates.\r\n  // Since 2011, Microsoft Excel on Mac OS uses year 1900 as the default baseline for cross-platform consistency.\r\n  // https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487\r\n  //\r\n  // So the 1904 baseline is now deprecated, although still available to be configured manually.\r\n  // So it still might be encountered in Excel files created on MacOS.\r\n  // In that case, the Excel file contains a special flag — `<workbook><workbookPr date1904=\"1\"/>...` —\r\n  // that tells the application which baseline is being used for numeric date timestamps.\r\n  //\r\n  if (options && options.epoch1904) {\r\n    // Convert the numeric date timestamp from 1904 baseline to 1900 baseline.\r\n    excelSerialDate += (1904 - 1900) * DAYS_IN_YEAR + JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY\r\n  }\r\n\r\n  const daysBeforeUnixEpoch = JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY + (1970 - 1900) * DAYS_IN_YEAR + NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970\r\n\r\n  return new Date(Math.floor((excelSerialDate - daysBeforeUnixEpoch) * DAY))\r\n}\r\n\r\n// \"Excel serial date\" is just a (fractional) count of days passed since `00/01/1900`.\r\n//\r\n// In contrast, \"Unix timestamps\" use `01/01/1970` as the baseline for numeric dates.\r\n//\r\n// In order to convert one into another, it should calculate the count of days elapsed\r\n// since `00/01/1900` (Excel epoch) till `01/01/1970` (Unix epoch), or the count of days\r\n// between year `1900` and year `1970`, plus one day.\r\n//\r\n// It also should account for the number of \"leap years\" between year `1900` and year `1970`,\r\n// which is 17 of them. https://kalender-365.de/leap-years.php\r\n//\r\n// \"One year has the length of 365 days, 5 hours, 48 minutes and 45 seconds.\r\n//  These are 365.2421875 days. This is hard to calculate with, so for practical reasons\r\n//  a normal year has been given 365 days and a leap year 366 days. In leap years,\r\n//  February 29th is added as leap day, which doesn't exist in a normal year.\r\n//  A leap year is every 4 years, but not every 100 years, then again every 400 years.\r\n//  So the year 1900 wasn't a leap year, but 2000 was\".\r\n//\r\n// And also, Excel has a historical bug when it incorrectly assumes year `1900` to be a leap year,\r\n// and, as a result, all Excel serial dates starting from March 1st, 1900 lag 1 day behind\r\n// and require an additional 1 day to be added to them in order to be converted to a proper timestamp.\r\n//\r\n// https://learn.microsoft.com/en-us/answers/questions/5249322/why-does-microsoft-excel-considers-29-02-1900-to-b?forum=msoffice-all&referrer=answers#:~:text=This%20made%20it%20easier%20for,other%20programs%20that%20use%20dates.\r\n//\r\n// \"When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year,\r\n//  even though it actually was not a leap year. This made it easier for the program to handle\r\n//  leap years and caused no harm to almost all date calculations in Lotus 1-2-3.\r\n//\r\n//  When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900\r\n//  was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use\r\n//  the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3.\r\n//  Treating 1900 as a leap year also made it easier for users to move worksheets from one program\r\n//  to the other\".\r\n//\r\n// So the historical bug is basically that Excel thinks that February 29th, 1900 existed\r\n// while in reality it didn't. That's why it's actually 1 day off for any date after that one.\r\n//\r\nconst NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970 = 17\r\nconst JANUARY_0TH_1900_DAY = 1\r\nconst ERRONEOUS_FEBRUARY_29_1990_DAY = 1\r\n\r\n// An approximate count of seconds in a day is:\r\n// 24 hours * 60 minutes in an hour * 60 seconds in a minute\r\n//\r\n// It is approximate because a minute could be longer than 60 seconds, due to \"leap seconds\".\r\n//\r\n// Still, javascript `Date`, and UNIX time in general, intentionally\r\n// drop the concept of \"leap seconds\" in order to make things simpler.\r\n// So this approximation is valid and doesn't result in any bugs.\r\n// https://stackoverflow.com/questions/53019726/where-are-the-leap-seconds-in-javascript\r\n//\r\n// \"The JavaScript Date object specifically adheres to the concept of Unix Time\r\n//  (albeit with higher precision). This is part of the POSIX specification,\r\n//  and thus is sometimes called \"POSIX Time\". It does not count leap seconds,\r\n//  but rather assumes every day had exactly 86,400 seconds. You can read about\r\n//  this in section 20.3.1.1 of the current ECMAScript specification, which states:\r\n//\r\n//  \"Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.\r\n//   In time values leap seconds are ignored. It is assumed that there are exactly\r\n//   86,400,000 milliseconds per day.\"\r\n//\r\n// The reason is that the unpredictable nature of leap seconds makes them very\r\n// difficult to work with in APIs. One can't generally pass timestamps around\r\n// that need leap seconds tables to be interpreted correctly, and expect that\r\n// one system will interpret them the same as another. For example, a timestamp\r\n// `1483228826` that accounts for \"leap seconds\" should've been interpreted as\r\n// \"2017-01-01T00:00:00Z\", but if the receiver doesn't account for \"leap seconds\",\r\n// they would interpret it as \"2017-01-01T00:00:26Z\" (e.g. POSIX-based systems like Linux),\r\n// So \"leap seconds\" aren't really portable.\r\n// Even on systems that have full frequently-updated \"leap second\" tables,\r\n// there's no telling what adjustments those tables will contain in the future\r\n// (i.e. beyond the 6-month IERS announcement period) because \"leap seconds\" can't be\r\n// determined by a fixed mathematical formula or something like that. Instead,\r\n// scientists introduce them as needed based on the observed Earth's rotation around the sun.\r\n//\r\n// \"Because the Earth's rotational speed varies in response to climatic and geological events,\r\n//  UTC leap seconds are irregularly spaced and not precisely predictable. The decision to insert\r\n// a leap second is made by the International Earth Rotation and Reference Systems Service (IERS),\r\n// typically about six months in advance, to ensure that the difference between UTC and UT1\r\n// does not exceed ±0.9 seconds.\"\r\n//\r\n// One example is year `1900` which is \"every fourth year\" but it still is not a \"leap year\".\r\n//\r\n// To reiterate: to support leap seconds in a programming language, the implementation\r\n// must go out of its way to do so, and must make tradeoffs that are not always acceptable.\r\n// Though there are exceptions, the general position is to not support them - not because\r\n// of any subversion or active countermeasures, but because supporting them properly is much,\r\n// much harder.\r\n//\r\n// https://en.wikipedia.org/wiki/Unix_time#Leap_seconds\r\n// https://en.wikipedia.org/wiki/Leap_year\r\n// https://en.wikipedia.org/wiki/Leap_second\r\n//\r\nconst DAY = 24 * 60 * 60 * 1000\r\nconst DAYS_IN_YEAR = 365\r\n"],"mappings":"AAAA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,eAAe,SAASA,cAAcA,CAACC,eAAe,EAAEC,OAAO,EAAE;EAC/D;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAIA,OAAO,IAAIA,OAAO,CAACC,SAAS,EAAE;IAChC;IACAF,eAAe,IAAI,CAAC,IAAI,GAAG,IAAI,IAAIG,YAAY,GAAGC,oBAAoB,GAAGC,8BAA8B;EACzG;EAEA,IAAMC,mBAAmB,GAAGF,oBAAoB,GAAGC,8BAA8B,GAAG,CAAC,IAAI,GAAG,IAAI,IAAIF,YAAY,GAAGI,0CAA0C;EAE7J,OAAO,IAAIC,IAAI,CAACC,IAAI,CAACC,KAAK,CAAC,CAACV,eAAe,GAAGM,mBAAmB,IAAIK,GAAG,CAAC,CAAC;AAC5E;;AAEA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,IAAMJ,0CAA0C,GAAG,EAAE;AACrD,IAAMH,oBAAoB,GAAG,CAAC;AAC9B,IAAMC,8BAA8B,GAAG,CAAC;;AAExC;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,IAAMM,GAAG,GAAG,EAAE,GAAG,EAAE,GAAG,EAAE,GAAG,IAAI;AAC/B,IAAMR,YAAY,GAAG,GAAG"}
+{"version":3,"file":"parseExcelDate.js","names":["parseExcelTimestamp","parseExcelDate","excelSerialDate","epoch1904","Date"],"sources":["../../source/xlsx/parseExcelDate.js"],"sourcesContent":["import parseExcelTimestamp from './parseExcelTimestamp.js'\r\n\r\n// Parses an Excel Date (represented by a \"serial\" floating-point number)\r\n// into a javascript `Date` in UTC+0 timezone (with time is set to 00:00).\r\n//\r\n// https://www.pcworld.com/article/3063622/software/mastering-excel-date-time-serial-numbers-networkdays-datevalue-and-more.html\r\n// \"If you need to calculate dates in your spreadsheets,\r\n//  Excel uses its own unique system, which it calls Serial Numbers\".\r\n//\r\nexport default function parseExcelDate(excelSerialDate, epoch1904) {\r\n  return new Date(parseExcelTimestamp(excelSerialDate, epoch1904))\r\n}"],"mappings":"AAAA,OAAOA,mBAAmB,MAAM,0BAA0B;;AAE1D;AACA;AACA;AACA;AACA;AACA;AACA;AACA,eAAe,SAASC,cAAcA,CAACC,eAAe,EAAEC,SAAS,EAAE;EACjE,OAAO,IAAIC,IAAI,CAACJ,mBAAmB,CAACE,eAAe,EAAEC,SAAS,CAAC,CAAC;AAClE"}

package/modules/xlsx/parseExcelDate.test.js.map

@@ -1 +1 @@
-{"version":3,"file":"parseExcelDate.test.js","names":["describe","it","expect","parseExcelDate","date","Date","UTC","getTime","to","equal","DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH","epoch1904"],"sources":["../../source/xlsx/parseExcelDate.test.js"],"sourcesContent":["import { describe, it } from 'mocha'\r\nimport { expect } from 'chai'\r\n\r\nimport parseExcelDate from './parseExcelDate.js'\r\n\r\ndescribe('parseExcelDate', () => {\r\n\tit('should parse Excel \"serial\" dates', () => {\r\n\t\tconst date = new Date(Date.UTC(2018, 3 - 1, 24))\r\n    // Excel stores dates as integers.\r\n    // E.g. '24/03/2018' === 43183\r\n\t\texpect(parseExcelDate(43183).getTime()).to.equal(date.getTime())\r\n\t})\r\n\r\n\tit('should parse Excel \"serial\" dates (1904 baseline)', () => {\r\n\t\tconst date = new Date(Date.UTC(2018, 3 - 1, 24))\r\n    // Excel stores dates as integers.\r\n    // E.g. '24/03/2018' === 43183\r\n\t\tconst DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH = 1462\r\n\t\texpect(parseExcelDate(43183 - DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH, { epoch1904: true }).getTime()).to.equal(date.getTime())\r\n\t})\r\n})\r\n"],"mappings":"AAAA,SAASA,QAAQ,EAAEC,EAAE,QAAQ,OAAO;AACpC,SAASC,MAAM,QAAQ,MAAM;AAE7B,OAAOC,cAAc,MAAM,qBAAqB;AAEhDH,QAAQ,CAAC,gBAAgB,EAAE,YAAM;EAChCC,EAAE,CAAC,mCAAmC,EAAE,YAAM;IAC7C,IAAMG,IAAI,GAAG,IAAIC,IAAI,CAACA,IAAI,CAACC,GAAG,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,CAAC;IAC9C;IACA;IACFJ,MAAM,CAACC,cAAc,CAAC,KAAK,CAAC,CAACI,OAAO,CAAC,CAAC,CAAC,CAACC,EAAE,CAACC,KAAK,CAACL,IAAI,CAACG,OAAO,CAAC,CAAC,CAAC;EACjE,CAAC,CAAC;EAEFN,EAAE,CAAC,mDAAmD,EAAE,YAAM;IAC7D,IAAMG,IAAI,GAAG,IAAIC,IAAI,CAACA,IAAI,CAACC,GAAG,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,CAAC;IAC9C;IACA;IACF,IAAMI,sCAAsC,GAAG,IAAI;IACnDR,MAAM,CAACC,cAAc,CAAC,KAAK,GAAGO,sCAAsC,EAAE;MAAEC,SAAS,EAAE;IAAK,CAAC,CAAC,CAACJ,OAAO,CAAC,CAAC,CAAC,CAACC,EAAE,CAACC,KAAK,CAACL,IAAI,CAACG,OAAO,CAAC,CAAC,CAAC;EAC/H,CAAC,CAAC;AACH,CAAC,CAAC"}
+{"version":3,"file":"parseExcelDate.test.js","names":["describe","it","expect","parseExcelDate","date","Date","UTC","getTime","to","equal","DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH"],"sources":["../../source/xlsx/parseExcelDate.test.js"],"sourcesContent":["import { describe, it } from 'mocha'\r\nimport { expect } from 'chai'\r\n\r\nimport parseExcelDate from './parseExcelDate.js'\r\n\r\ndescribe('parseExcelDate', () => {\r\n\tit('should parse Excel \"serial\" dates', () => {\r\n\t\tconst date = new Date(Date.UTC(2018, 3 - 1, 24))\r\n    // Excel stores dates as integers.\r\n    // E.g. '24/03/2018' === 43183\r\n\t\texpect(parseExcelDate(43183).getTime()).to.equal(date.getTime())\r\n\t})\r\n\r\n\tit('should parse Excel \"serial\" dates (1904 baseline)', () => {\r\n\t\tconst date = new Date(Date.UTC(2018, 3 - 1, 24))\r\n    // Excel stores dates as integers.\r\n    // E.g. '24/03/2018' === 43183\r\n\t\tconst DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH = 1462\r\n\t\texpect(parseExcelDate(43183 - DAYS_BETWEEN_1900_EPOCH_AND_1904_EPOCH, true).getTime()).to.equal(date.getTime())\r\n\t})\r\n})\r\n"],"mappings":"AAAA,SAASA,QAAQ,EAAEC,EAAE,QAAQ,OAAO;AACpC,SAASC,MAAM,QAAQ,MAAM;AAE7B,OAAOC,cAAc,MAAM,qBAAqB;AAEhDH,QAAQ,CAAC,gBAAgB,EAAE,YAAM;EAChCC,EAAE,CAAC,mCAAmC,EAAE,YAAM;IAC7C,IAAMG,IAAI,GAAG,IAAIC,IAAI,CAACA,IAAI,CAACC,GAAG,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,CAAC;IAC9C;IACA;IACFJ,MAAM,CAACC,cAAc,CAAC,KAAK,CAAC,CAACI,OAAO,CAAC,CAAC,CAAC,CAACC,EAAE,CAACC,KAAK,CAACL,IAAI,CAACG,OAAO,CAAC,CAAC,CAAC;EACjE,CAAC,CAAC;EAEFN,EAAE,CAAC,mDAAmD,EAAE,YAAM;IAC7D,IAAMG,IAAI,GAAG,IAAIC,IAAI,CAACA,IAAI,CAACC,GAAG,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,CAAC;IAC9C;IACA;IACF,IAAMI,sCAAsC,GAAG,IAAI;IACnDR,MAAM,CAACC,cAAc,CAAC,KAAK,GAAGO,sCAAsC,EAAE,IAAI,CAAC,CAACH,OAAO,CAAC,CAAC,CAAC,CAACC,EAAE,CAACC,KAAK,CAACL,IAAI,CAACG,OAAO,CAAC,CAAC,CAAC;EAChH,CAAC,CAAC;AACH,CAAC,CAAC"}

package/modules/xlsx/parseExcelTimestamp.js

@@ -0,0 +1,133 @@
+// Parses an Excel Date (represented by a "serial" floating-point number)
+// into a javascript `Date` timestamp in UTC+0 timezone (with time is set to 00:00).
+//
+// https://www.pcworld.com/article/3063622/software/mastering-excel-date-time-serial-numbers-networkdays-datevalue-and-more.html
+// "If you need to calculate dates in your spreadsheets,
+//  Excel uses its own unique system, which it calls Serial Numbers".
+//
+export default function parseExcelTimestamp(excelSerialDate, epoch1904) {
+  // "Excel serial date" is just a (fractional) count of days passed since `00/01/1900`.
+  //
+  // In contrast, "Unix timestamps" use `01/01/1970` as the baseline for numeric dates.
+  //
+  // In order to convert one into another, it should calculate the count of days elapsed
+  // since `00/01/1900` (Excel epoch) till `01/01/1970` (Unix epoch), or the count of days
+  // between year `1900` and year `1970`, plus one day.
+  //
+  // It also should account for the number of "leap years" between year `1900` and year `1970`,
+  // which is 17 of them. https://kalender-365.de/leap-years.php
+  //
+  // "One year has the length of 365 days, 5 hours, 48 minutes and 45 seconds.
+  //  These are 365.2421875 days. This is hard to calculate with, so for practical reasons
+  //  a normal year has been given 365 days and a leap year 366 days. In leap years,
+  //  February 29th is added as leap day, which doesn't exist in a normal year.
+  //  A leap year is every 4 years, but not every 100 years, then again every 400 years.
+  //  So the year 1900 wasn't a leap year, but 2000 was".
+  //
+  // And also, Excel has a historical bug when it incorrectly assumes year `1900` to be a leap year,
+  // and, as a result, all Excel serial dates starting from March 1st, 1900 lag 1 day behind
+  // and require an additional 1 day to be added to them in order to be converted to a proper timestamp.
+  //
+  // https://learn.microsoft.com/en-us/answers/questions/5249322/why-does-microsoft-excel-considers-29-02-1900-to-b?forum=msoffice-all&referrer=answers#:~:text=This%20made%20it%20easier%20for,other%20programs%20that%20use%20dates.
+  //
+  // "When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year,
+  //  even though it actually was not a leap year. This made it easier for the program to handle
+  //  leap years and caused no harm to almost all date calculations in Lotus 1-2-3.
+  //
+  //  When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900
+  //  was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use
+  //  the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3.
+  //  Treating 1900 as a leap year also made it easier for users to move worksheets from one program
+  //  to the other".
+  //
+  // So the historical bug is basically that Excel thinks that February 29th, 1900 existed
+  // while in reality it didn't. That's why it's actually 1 day off for any date after that one.
+  //
+  var NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970 = 17;
+  var JANUARY_0TH_1900_DAY = 1;
+  var ERRONEOUS_FEBRUARY_29_1990_DAY = 1;
+
+  // An approximate count of seconds in a day is:
+  // 24 hours * 60 minutes in an hour * 60 seconds in a minute
+  //
+  // It is approximate because a minute could be longer than 60 seconds, due to "leap seconds".
+  //
+  // Still, javascript `Date`, and UNIX time in general, intentionally
+  // drop the concept of "leap seconds" in order to make things simpler.
+  // So this approximation is valid and doesn't result in any bugs.
+  // https://stackoverflow.com/questions/53019726/where-are-the-leap-seconds-in-javascript
+  //
+  // "The JavaScript Date object specifically adheres to the concept of Unix Time
+  //  (albeit with higher precision). This is part of the POSIX specification,
+  //  and thus is sometimes called "POSIX Time". It does not count leap seconds,
+  //  but rather assumes every day had exactly 86,400 seconds. You can read about
+  //  this in section 20.3.1.1 of the current ECMAScript specification, which states:
+  //
+  //  "Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.
+  //   In time values leap seconds are ignored. It is assumed that there are exactly
+  //   86,400,000 milliseconds per day."
+  //
+  // The reason is that the unpredictable nature of leap seconds makes them very
+  // difficult to work with in APIs. One can't generally pass timestamps around
+  // that need leap seconds tables to be interpreted correctly, and expect that
+  // one system will interpret them the same as another. For example, a timestamp
+  // `1483228826` that accounts for "leap seconds" should've been interpreted as
+  // "2017-01-01T00:00:00Z", but if the receiver doesn't account for "leap seconds",
+  // they would interpret it as "2017-01-01T00:00:26Z" (e.g. POSIX-based systems like Linux),
+  // So "leap seconds" aren't really portable.
+  // Even on systems that have full frequently-updated "leap second" tables,
+  // there's no telling what adjustments those tables will contain in the future
+  // (i.e. beyond the 6-month IERS announcement period) because "leap seconds" can't be
+  // determined by a fixed mathematical formula or something like that. Instead,
+  // scientists introduce them as needed based on the observed Earth's rotation around the sun.
+  //
+  // "Because the Earth's rotational speed varies in response to climatic and geological events,
+  //  UTC leap seconds are irregularly spaced and not precisely predictable. The decision to insert
+  // a leap second is made by the International Earth Rotation and Reference Systems Service (IERS),
+  // typically about six months in advance, to ensure that the difference between UTC and UT1
+  // does not exceed ±0.9 seconds."
+  //
+  // One example is year `1900` which is "every fourth year" but it still is not a "leap year".
+  //
+  // To reiterate: to support leap seconds in a programming language, the implementation
+  // must go out of its way to do so, and must make tradeoffs that are not always acceptable.
+  // Though there are exceptions, the general position is to not support them - not because
+  // of any subversion or active countermeasures, but because supporting them properly is much,
+  // much harder.
+  //
+  // https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
+  // https://en.wikipedia.org/wiki/Leap_year
+  // https://en.wikipedia.org/wiki/Leap_second
+  //
+  var DAY = 24 * 60 * 60 * 1000;
+  var DAYS_IN_YEAR = 365;
+
+  // Windows operating system uses floating-point numbers to represent dates,
+  // where the number represents the count of days elapsed since January 0th, 1900.
+  //
+  // This also means that there're 2 aspects associated with this choice:
+  //
+  // * January 1st, 1900, 00:00 is represented by `1` rather than `0`, which looks a bit weird.
+  // * 1900 is a special year because it's a "one in a 100 years" occasion when it's not a leap year.
+  //
+  // To work around those two aspects, Mac OS chose another baseline — January 1st, 1900.
+  // Although, that only postponed the second issue because 2100 is going to be the next "speciaL" year
+  // which is not going to be a "leap" one.
+  //
+  // Older versions of Excel on Mac OS used year 1904 as the default baseline for numeric dates.
+  // Since 2011, Microsoft Excel on Mac OS uses year 1900 as the default baseline for cross-platform consistency.
+  // https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487
+  //
+  // So the 1904 baseline is now deprecated, although still available to be configured manually.
+  // So it still might be encountered in Excel files created on MacOS.
+  // In that case, the Excel file contains a special flag — `<workbook><workbookPr date1904="1"/>...` —
+  // that tells the application which baseline is being used for numeric date timestamps.
+  //
+  if (epoch1904) {
+    // Convert the numeric date timestamp from 1904 baseline to 1900 baseline.
+    excelSerialDate += (1904 - 1900) * DAYS_IN_YEAR + JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY;
+  }
+  var daysBeforeUnixEpoch = JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY + (1970 - 1900) * DAYS_IN_YEAR + NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970;
+  return Math.floor((excelSerialDate - daysBeforeUnixEpoch) * DAY);
+}
+//# sourceMappingURL=parseExcelTimestamp.js.map

package/modules/xlsx/parseExcelTimestamp.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"parseExcelTimestamp.js","names":["parseExcelTimestamp","excelSerialDate","epoch1904","NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970","JANUARY_0TH_1900_DAY","ERRONEOUS_FEBRUARY_29_1990_DAY","DAY","DAYS_IN_YEAR","daysBeforeUnixEpoch","Math","floor"],"sources":["../../source/xlsx/parseExcelTimestamp.js"],"sourcesContent":["// Parses an Excel Date (represented by a \"serial\" floating-point number)\r\n// into a javascript `Date` timestamp in UTC+0 timezone (with time is set to 00:00).\r\n//\r\n// https://www.pcworld.com/article/3063622/software/mastering-excel-date-time-serial-numbers-networkdays-datevalue-and-more.html\r\n// \"If you need to calculate dates in your spreadsheets,\r\n//  Excel uses its own unique system, which it calls Serial Numbers\".\r\n//\r\nexport default function parseExcelTimestamp(excelSerialDate, epoch1904) {\r\n  // \"Excel serial date\" is just a (fractional) count of days passed since `00/01/1900`.\r\n  //\r\n  // In contrast, \"Unix timestamps\" use `01/01/1970` as the baseline for numeric dates.\r\n  //\r\n  // In order to convert one into another, it should calculate the count of days elapsed\r\n  // since `00/01/1900` (Excel epoch) till `01/01/1970` (Unix epoch), or the count of days\r\n  // between year `1900` and year `1970`, plus one day.\r\n  //\r\n  // It also should account for the number of \"leap years\" between year `1900` and year `1970`,\r\n  // which is 17 of them. https://kalender-365.de/leap-years.php\r\n  //\r\n  // \"One year has the length of 365 days, 5 hours, 48 minutes and 45 seconds.\r\n  //  These are 365.2421875 days. This is hard to calculate with, so for practical reasons\r\n  //  a normal year has been given 365 days and a leap year 366 days. In leap years,\r\n  //  February 29th is added as leap day, which doesn't exist in a normal year.\r\n  //  A leap year is every 4 years, but not every 100 years, then again every 400 years.\r\n  //  So the year 1900 wasn't a leap year, but 2000 was\".\r\n  //\r\n  // And also, Excel has a historical bug when it incorrectly assumes year `1900` to be a leap year,\r\n  // and, as a result, all Excel serial dates starting from March 1st, 1900 lag 1 day behind\r\n  // and require an additional 1 day to be added to them in order to be converted to a proper timestamp.\r\n  //\r\n  // https://learn.microsoft.com/en-us/answers/questions/5249322/why-does-microsoft-excel-considers-29-02-1900-to-b?forum=msoffice-all&referrer=answers#:~:text=This%20made%20it%20easier%20for,other%20programs%20that%20use%20dates.\r\n  //\r\n  // \"When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year,\r\n  //  even though it actually was not a leap year. This made it easier for the program to handle\r\n  //  leap years and caused no harm to almost all date calculations in Lotus 1-2-3.\r\n  //\r\n  //  When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900\r\n  //  was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use\r\n  //  the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3.\r\n  //  Treating 1900 as a leap year also made it easier for users to move worksheets from one program\r\n  //  to the other\".\r\n  //\r\n  // So the historical bug is basically that Excel thinks that February 29th, 1900 existed\r\n  // while in reality it didn't. That's why it's actually 1 day off for any date after that one.\r\n  //\r\n  const NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970 = 17\r\n  const JANUARY_0TH_1900_DAY = 1\r\n  const ERRONEOUS_FEBRUARY_29_1990_DAY = 1\r\n\r\n  // An approximate count of seconds in a day is:\r\n  // 24 hours * 60 minutes in an hour * 60 seconds in a minute\r\n  //\r\n  // It is approximate because a minute could be longer than 60 seconds, due to \"leap seconds\".\r\n  //\r\n  // Still, javascript `Date`, and UNIX time in general, intentionally\r\n  // drop the concept of \"leap seconds\" in order to make things simpler.\r\n  // So this approximation is valid and doesn't result in any bugs.\r\n  // https://stackoverflow.com/questions/53019726/where-are-the-leap-seconds-in-javascript\r\n  //\r\n  // \"The JavaScript Date object specifically adheres to the concept of Unix Time\r\n  //  (albeit with higher precision). This is part of the POSIX specification,\r\n  //  and thus is sometimes called \"POSIX Time\". It does not count leap seconds,\r\n  //  but rather assumes every day had exactly 86,400 seconds. You can read about\r\n  //  this in section 20.3.1.1 of the current ECMAScript specification, which states:\r\n  //\r\n  //  \"Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.\r\n  //   In time values leap seconds are ignored. It is assumed that there are exactly\r\n  //   86,400,000 milliseconds per day.\"\r\n  //\r\n  // The reason is that the unpredictable nature of leap seconds makes them very\r\n  // difficult to work with in APIs. One can't generally pass timestamps around\r\n  // that need leap seconds tables to be interpreted correctly, and expect that\r\n  // one system will interpret them the same as another. For example, a timestamp\r\n  // `1483228826` that accounts for \"leap seconds\" should've been interpreted as\r\n  // \"2017-01-01T00:00:00Z\", but if the receiver doesn't account for \"leap seconds\",\r\n  // they would interpret it as \"2017-01-01T00:00:26Z\" (e.g. POSIX-based systems like Linux),\r\n  // So \"leap seconds\" aren't really portable.\r\n  // Even on systems that have full frequently-updated \"leap second\" tables,\r\n  // there's no telling what adjustments those tables will contain in the future\r\n  // (i.e. beyond the 6-month IERS announcement period) because \"leap seconds\" can't be\r\n  // determined by a fixed mathematical formula or something like that. Instead,\r\n  // scientists introduce them as needed based on the observed Earth's rotation around the sun.\r\n  //\r\n  // \"Because the Earth's rotational speed varies in response to climatic and geological events,\r\n  //  UTC leap seconds are irregularly spaced and not precisely predictable. The decision to insert\r\n  // a leap second is made by the International Earth Rotation and Reference Systems Service (IERS),\r\n  // typically about six months in advance, to ensure that the difference between UTC and UT1\r\n  // does not exceed ±0.9 seconds.\"\r\n  //\r\n  // One example is year `1900` which is \"every fourth year\" but it still is not a \"leap year\".\r\n  //\r\n  // To reiterate: to support leap seconds in a programming language, the implementation\r\n  // must go out of its way to do so, and must make tradeoffs that are not always acceptable.\r\n  // Though there are exceptions, the general position is to not support them - not because\r\n  // of any subversion or active countermeasures, but because supporting them properly is much,\r\n  // much harder.\r\n  //\r\n  // https://en.wikipedia.org/wiki/Unix_time#Leap_seconds\r\n  // https://en.wikipedia.org/wiki/Leap_year\r\n  // https://en.wikipedia.org/wiki/Leap_second\r\n  //\r\n  const DAY = 24 * 60 * 60 * 1000\r\n  const DAYS_IN_YEAR = 365\r\n\r\n  // Windows operating system uses floating-point numbers to represent dates,\r\n  // where the number represents the count of days elapsed since January 0th, 1900.\r\n  //\r\n  // This also means that there're 2 aspects associated with this choice:\r\n  //\r\n  // * January 1st, 1900, 00:00 is represented by `1` rather than `0`, which looks a bit weird.\r\n  // * 1900 is a special year because it's a \"one in a 100 years\" occasion when it's not a leap year.\r\n  //\r\n  // To work around those two aspects, Mac OS chose another baseline — January 1st, 1900.\r\n  // Although, that only postponed the second issue because 2100 is going to be the next \"speciaL\" year\r\n  // which is not going to be a \"leap\" one.\r\n  //\r\n  // Older versions of Excel on Mac OS used year 1904 as the default baseline for numeric dates.\r\n  // Since 2011, Microsoft Excel on Mac OS uses year 1900 as the default baseline for cross-platform consistency.\r\n  // https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487\r\n  //\r\n  // So the 1904 baseline is now deprecated, although still available to be configured manually.\r\n  // So it still might be encountered in Excel files created on MacOS.\r\n  // In that case, the Excel file contains a special flag — `<workbook><workbookPr date1904=\"1\"/>...` —\r\n  // that tells the application which baseline is being used for numeric date timestamps.\r\n  //\r\n  if (epoch1904) {\r\n    // Convert the numeric date timestamp from 1904 baseline to 1900 baseline.\r\n    excelSerialDate += (1904 - 1900) * DAYS_IN_YEAR + JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY\r\n  }\r\n\r\n  const daysBeforeUnixEpoch = JANUARY_0TH_1900_DAY + ERRONEOUS_FEBRUARY_29_1990_DAY + (1970 - 1900) * DAYS_IN_YEAR + NUMBER_OF_LEAP_YEARS_BETWEEN_1900_AND_1970\r\n\r\n  return Math.floor((excelSerialDate - daysBeforeUnixEpoch) * DAY)\r\n}"],"mappings":"AAAA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,eAAe,SAASA,mBAAmBA,CAACC,eAAe,EAAEC,SAAS,EAAE;EACtE;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAMC,0CAA0C,GAAG,EAAE;EACrD,IAAMC,oBAAoB,GAAG,CAAC;EAC9B,IAAMC,8BAA8B,GAAG,CAAC;;EAExC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAMC,GAAG,GAAG,EAAE,GAAG,EAAE,GAAG,EAAE,GAAG,IAAI;EAC/B,IAAMC,YAAY,GAAG,GAAG;;EAExB;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAIL,SAAS,EAAE;IACb;IACAD,eAAe,IAAI,CAAC,IAAI,GAAG,IAAI,IAAIM,YAAY,GAAGH,oBAAoB,GAAGC,8BAA8B;EACzG;EAEA,IAAMG,mBAAmB,GAAGJ,oBAAoB,GAAGC,8BAA8B,GAAG,CAAC,IAAI,GAAG,IAAI,IAAIE,YAAY,GAAGJ,0CAA0C;EAE7J,OAAOM,IAAI,CAACC,KAAK,CAAC,CAACT,eAAe,GAAGO,mBAAmB,IAAIF,GAAG,CAAC;AAClE"}

package/modules/xlsx/parseFilePaths.js

@@ -4,10 +4,10 @@
  * is `xl/_rels/workbook.xml.rels` file.
  * https://github.com/tidyverse/readxl/issues/104
  * @param  {string} content — `xl/_rels/workbook.xml.rels` file contents.
- * @param  {function} parseXmlStream — SAX XML parser.
+ * @param  {function} parseXml — SAX XML parser.
  * @return {object} — An object of shape `{ sheets: Record<string, string>, sharedStrings: string?, styles: string? }`
  */
-export default function parseFilePaths(content, parseXmlStream) {
+export default function parseFilePaths(content, parseXml) {
   // Example:
   // <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
   //   ...
@@ -16,54 +16,55 @@ export default function parseFilePaths(content, parseXmlStream) {
   //     Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet"
   //     Target="worksheets/sheet1.xml"/>
   // </Relationships>
-  return parseXmlStream(content, {
-    createInitialState: createInitialStateInWorkbookRelationships,
-    onOpenTag: onOpenTagInWorkbookRelationships
-  }).then(function (state) {
-    return state;
+  var state = createInitialState();
+  return parseXml(content, state, onOpenTag, null, null).then(function () {
+    return getResultFromState(state);
   });
-}
-function createInitialStateInWorkbookRelationships() {
-  return {
-    sheets: {},
-    sharedStrings: undefined,
-    styles: undefined
-  };
-}
-function onOpenTagInWorkbookRelationships(tagName, attributes, state) {
-  if (tagName === 'Relationship') {
-    addFilePathForRelation(state, attributes.Id, attributes.Type, attributes.Target);
+  function createInitialState() {
+    return {
+      sheets: {},
+      sharedStrings: undefined,
+      styles: undefined
+    };
   }
-}
-function addFilePathForRelation(state, id, type, target) {
-  switch (type) {
-    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles':
-      state.styles = getFilePathFromRelationTarget(target);
-      break;
-    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/sharedStrings':
-      state.sharedStrings = getFilePathFromRelationTarget(target);
-      break;
-    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet':
-      state.sheets[id] = getFilePathFromRelationTarget(target);
-      break;
+  function getResultFromState(state) {
+    return state;
   }
-}
-function getFilePathFromRelationTarget(path) {
-  // Normally, `path` is a relative path inside the ZIP archive,
-  // like "worksheets/sheet1.xml", or "sharedStrings.xml", or "styles.xml".
-  // There has been one weird case when file path was an absolute path,
-  // like "/xl/worksheets/sheet1.xml" (specifically for sheets):
-  // https://github.com/catamphetamine/read-excel-file/pull/95
-  // Other libraries (like `xlsx`) and software (like Google Docs)
-  // seem to support such absolute file paths, so this library does too.
-  if (path[0] === '/') {
-    return path.slice('/'.length);
+  function onOpenTag(tagName, attributes, state) {
+    if (tagName === 'Relationship') {
+      addFilePathForRelation(state, attributes.Id, attributes.Type, attributes.Target);
+    }
+  }
+  function addFilePathForRelation(state, id, type, target) {
+    switch (type) {
+      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles':
+        state.styles = getFilePathFromRelationTarget(target);
+        break;
+      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/sharedStrings':
+        state.sharedStrings = getFilePathFromRelationTarget(target);
+        break;
+      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet':
+        state.sheets[id] = getFilePathFromRelationTarget(target);
+        break;
+    }
+  }
+  function getFilePathFromRelationTarget(path) {
+    // Normally, `path` is a relative path inside the ZIP archive,
+    // like "worksheets/sheet1.xml", or "sharedStrings.xml", or "styles.xml".
+    // There has been one weird case when file path was an absolute path,
+    // like "/xl/worksheets/sheet1.xml" (specifically for sheets):
+    // https://github.com/catamphetamine/read-excel-file/pull/95
+    // Other libraries (like `xlsx`) and software (like Google Docs)
+    // seem to support such absolute file paths, so this library does too.
+    if (path[0] === '/') {
+      return path.slice('/'.length);
+    }
+    // // Seems like a path could also be a URL.
+    // // http://officeopenxml.com/anatomyofOOXML-xlsx.php
+    // if (/^[a-z]+\:\/\//.test(path)) {
+    //   return path
+    // }
+    return 'xl/' + path;
   }
-  // // Seems like a path could also be a URL.
-  // // http://officeopenxml.com/anatomyofOOXML-xlsx.php
-  // if (/^[a-z]+\:\/\//.test(path)) {
-  //   return path
-  // }
-  return 'xl/' + path;
 }
 //# sourceMappingURL=parseFilePaths.js.map

package/modules/xlsx/parseFilePaths.js.map

@@ -1 +1 @@
-{"version":3,"file":"parseFilePaths.js","names":["parseFilePaths","content","parseXmlStream","createInitialState","createInitialStateInWorkbookRelationships","onOpenTag","onOpenTagInWorkbookRelationships","then","state","sheets","sharedStrings","undefined","styles","tagName","attributes","addFilePathForRelation","Id","Type","Target","id","type","target","getFilePathFromRelationTarget","path","slice","length"],"sources":["../../source/xlsx/parseFilePaths.js"],"sourcesContent":["/**\r\n * Returns sheet file paths.\r\n * Seems that the correct place to look for the `sheetId` -> `filename` mapping\r\n * is `xl/_rels/workbook.xml.rels` file.\r\n * https://github.com/tidyverse/readxl/issues/104\r\n * @param  {string} content — `xl/_rels/workbook.xml.rels` file contents.\r\n * @param  {function} parseXmlStream — SAX XML parser.\r\n * @return {object} — An object of shape `{ sheets: Record<string, string>, sharedStrings: string?, styles: string? }`\r\n */\r\nexport default function parseFilePaths(content, parseXmlStream) {\r\n  // Example:\r\n  // <Relationships xmlns=\"http://schemas.openxmlformats.org/package/2006/relationships\">\r\n  //   ...\r\n  //   <Relationship\r\n  //     Id=\"rId3\"\r\n  //     Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet\"\r\n  //     Target=\"worksheets/sheet1.xml\"/>\r\n  // </Relationships>\r\n  return parseXmlStream(content, {\r\n    createInitialState: createInitialStateInWorkbookRelationships,\r\n    onOpenTag: onOpenTagInWorkbookRelationships\r\n  }).then((state) => {\r\n    return state\r\n  })\r\n}\r\n\r\nfunction createInitialStateInWorkbookRelationships() {\r\n  return {\r\n    sheets: {},\r\n    sharedStrings: undefined,\r\n    styles: undefined\r\n  }\r\n}\r\n\r\nfunction onOpenTagInWorkbookRelationships(tagName, attributes, state) {\r\n  if (tagName === 'Relationship') {\r\n    addFilePathForRelation(state, attributes.Id, attributes.Type, attributes.Target)\r\n  }\r\n}\r\n\r\nfunction addFilePathForRelation(state, id, type, target) {\r\n  switch (type) {\r\n    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles':\r\n      state.styles = getFilePathFromRelationTarget(target)\r\n      break\r\n    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/sharedStrings':\r\n      state.sharedStrings = getFilePathFromRelationTarget(target)\r\n      break\r\n    case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet':\r\n      state.sheets[id] = getFilePathFromRelationTarget(target)\r\n      break\r\n  }\r\n}\r\n\r\nfunction getFilePathFromRelationTarget(path) {\r\n  // Normally, `path` is a relative path inside the ZIP archive,\r\n  // like \"worksheets/sheet1.xml\", or \"sharedStrings.xml\", or \"styles.xml\".\r\n  // There has been one weird case when file path was an absolute path,\r\n  // like \"/xl/worksheets/sheet1.xml\" (specifically for sheets):\r\n  // https://github.com/catamphetamine/read-excel-file/pull/95\r\n  // Other libraries (like `xlsx`) and software (like Google Docs)\r\n  // seem to support such absolute file paths, so this library does too.\r\n  if (path[0] === '/') {\r\n    return path.slice('/'.length)\r\n  }\r\n  // // Seems like a path could also be a URL.\r\n  // // http://officeopenxml.com/anatomyofOOXML-xlsx.php\r\n  // if (/^[a-z]+\\:\\/\\//.test(path)) {\r\n  //   return path\r\n  // }\r\n  return 'xl/' + path\r\n}\r\n"],"mappings":"AAAA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,eAAe,SAASA,cAAcA,CAACC,OAAO,EAAEC,cAAc,EAAE;EAC9D;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,OAAOA,cAAc,CAACD,OAAO,EAAE;IAC7BE,kBAAkB,EAAEC,yCAAyC;IAC7DC,SAAS,EAAEC;EACb,CAAC,CAAC,CAACC,IAAI,CAAC,UAACC,KAAK,EAAK;IACjB,OAAOA,KAAK;EACd,CAAC,CAAC;AACJ;AAEA,SAASJ,yCAAyCA,CAAA,EAAG;EACnD,OAAO;IACLK,MAAM,EAAE,CAAC,CAAC;IACVC,aAAa,EAAEC,SAAS;IACxBC,MAAM,EAAED;EACV,CAAC;AACH;AAEA,SAASL,gCAAgCA,CAACO,OAAO,EAAEC,UAAU,EAAEN,KAAK,EAAE;EACpE,IAAIK,OAAO,KAAK,cAAc,EAAE;IAC9BE,sBAAsB,CAACP,KAAK,EAAEM,UAAU,CAACE,EAAE,EAAEF,UAAU,CAACG,IAAI,EAAEH,UAAU,CAACI,MAAM,CAAC;EAClF;AACF;AAEA,SAASH,sBAAsBA,CAACP,KAAK,EAAEW,EAAE,EAAEC,IAAI,EAAEC,MAAM,EAAE;EACvD,QAAQD,IAAI;IACV,KAAK,4EAA4E;MAC/EZ,KAAK,CAACI,MAAM,GAAGU,6BAA6B,CAACD,MAAM,CAAC;MACpD;IACF,KAAK,mFAAmF;MACtFb,KAAK,CAACE,aAAa,GAAGY,6BAA6B,CAACD,MAAM,CAAC;MAC3D;IACF,KAAK,+EAA+E;MAClFb,KAAK,CAACC,MAAM,CAACU,EAAE,CAAC,GAAGG,6BAA6B,CAACD,MAAM,CAAC;MACxD;EACJ;AACF;AAEA,SAASC,6BAA6BA,CAACC,IAAI,EAAE;EAC3C;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAIA,IAAI,CAAC,CAAC,CAAC,KAAK,GAAG,EAAE;IACnB,OAAOA,IAAI,CAACC,KAAK,CAAC,GAAG,CAACC,MAAM,CAAC;EAC/B;EACA;EACA;EACA;EACA;EACA;EACA,OAAO,KAAK,GAAGF,IAAI;AACrB"}
+{"version":3,"file":"parseFilePaths.js","names":["parseFilePaths","content","parseXml","state","createInitialState","onOpenTag","then","getResultFromState","sheets","sharedStrings","undefined","styles","tagName","attributes","addFilePathForRelation","Id","Type","Target","id","type","target","getFilePathFromRelationTarget","path","slice","length"],"sources":["../../source/xlsx/parseFilePaths.js"],"sourcesContent":["/**\r\n * Returns sheet file paths.\r\n * Seems that the correct place to look for the `sheetId` -> `filename` mapping\r\n * is `xl/_rels/workbook.xml.rels` file.\r\n * https://github.com/tidyverse/readxl/issues/104\r\n * @param  {string} content — `xl/_rels/workbook.xml.rels` file contents.\r\n * @param  {function} parseXml — SAX XML parser.\r\n * @return {object} — An object of shape `{ sheets: Record<string, string>, sharedStrings: string?, styles: string? }`\r\n */\r\nexport default function parseFilePaths(content, parseXml) {\r\n  // Example:\r\n  // <Relationships xmlns=\"http://schemas.openxmlformats.org/package/2006/relationships\">\r\n  //   ...\r\n  //   <Relationship\r\n  //     Id=\"rId3\"\r\n  //     Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet\"\r\n  //     Target=\"worksheets/sheet1.xml\"/>\r\n  // </Relationships>\r\n  const state = createInitialState()\r\n  return parseXml(\r\n    content,\r\n    state,\r\n    onOpenTag,\r\n    null,\r\n    null\r\n  ).then(() => getResultFromState(state))\r\n\r\n  function createInitialState() {\r\n    return {\r\n      sheets: {},\r\n      sharedStrings: undefined,\r\n      styles: undefined\r\n    }\r\n  }\r\n\r\n  function getResultFromState(state) {\r\n    return state\r\n  }\r\n\r\n  function onOpenTag(tagName, attributes, state) {\r\n    if (tagName === 'Relationship') {\r\n      addFilePathForRelation(state, attributes.Id, attributes.Type, attributes.Target)\r\n    }\r\n  }\r\n\r\n  function addFilePathForRelation(state, id, type, target) {\r\n    switch (type) {\r\n      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles':\r\n        state.styles = getFilePathFromRelationTarget(target)\r\n        break\r\n      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/sharedStrings':\r\n        state.sharedStrings = getFilePathFromRelationTarget(target)\r\n        break\r\n      case 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet':\r\n        state.sheets[id] = getFilePathFromRelationTarget(target)\r\n        break\r\n    }\r\n  }\r\n\r\n  function getFilePathFromRelationTarget(path) {\r\n    // Normally, `path` is a relative path inside the ZIP archive,\r\n    // like \"worksheets/sheet1.xml\", or \"sharedStrings.xml\", or \"styles.xml\".\r\n    // There has been one weird case when file path was an absolute path,\r\n    // like \"/xl/worksheets/sheet1.xml\" (specifically for sheets):\r\n    // https://github.com/catamphetamine/read-excel-file/pull/95\r\n    // Other libraries (like `xlsx`) and software (like Google Docs)\r\n    // seem to support such absolute file paths, so this library does too.\r\n    if (path[0] === '/') {\r\n      return path.slice('/'.length)\r\n    }\r\n    // // Seems like a path could also be a URL.\r\n    // // http://officeopenxml.com/anatomyofOOXML-xlsx.php\r\n    // if (/^[a-z]+\\:\\/\\//.test(path)) {\r\n    //   return path\r\n    // }\r\n    return 'xl/' + path\r\n  }\r\n}"],"mappings":"AAAA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,eAAe,SAASA,cAAcA,CAACC,OAAO,EAAEC,QAAQ,EAAE;EACxD;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA,IAAMC,KAAK,GAAGC,kBAAkB,CAAC,CAAC;EAClC,OAAOF,QAAQ,CACbD,OAAO,EACPE,KAAK,EACLE,SAAS,EACT,IAAI,EACJ,IACF,CAAC,CAACC,IAAI,CAAC;IAAA,OAAMC,kBAAkB,CAACJ,KAAK,CAAC;EAAA,EAAC;EAEvC,SAASC,kBAAkBA,CAAA,EAAG;IAC5B,OAAO;MACLI,MAAM,EAAE,CAAC,CAAC;MACVC,aAAa,EAAEC,SAAS;MACxBC,MAAM,EAAED;IACV,CAAC;EACH;EAEA,SAASH,kBAAkBA,CAACJ,KAAK,EAAE;IACjC,OAAOA,KAAK;EACd;EAEA,SAASE,SAASA,CAACO,OAAO,EAAEC,UAAU,EAAEV,KAAK,EAAE;IAC7C,IAAIS,OAAO,KAAK,cAAc,EAAE;MAC9BE,sBAAsB,CAACX,KAAK,EAAEU,UAAU,CAACE,EAAE,EAAEF,UAAU,CAACG,IAAI,EAAEH,UAAU,CAACI,MAAM,CAAC;IAClF;EACF;EAEA,SAASH,sBAAsBA,CAACX,KAAK,EAAEe,EAAE,EAAEC,IAAI,EAAEC,MAAM,EAAE;IACvD,QAAQD,IAAI;MACV,KAAK,4EAA4E;QAC/EhB,KAAK,CAACQ,MAAM,GAAGU,6BAA6B,CAACD,MAAM,CAAC;QACpD;MACF,KAAK,mFAAmF;QACtFjB,KAAK,CAACM,aAAa,GAAGY,6BAA6B,CAACD,MAAM,CAAC;QAC3D;MACF,KAAK,+EAA+E;QAClFjB,KAAK,CAACK,MAAM,CAACU,EAAE,CAAC,GAAGG,6BAA6B,CAACD,MAAM,CAAC;QACxD;IACJ;EACF;EAEA,SAASC,6BAA6BA,CAACC,IAAI,EAAE;IAC3C;IACA;IACA;IACA;IACA;IACA;IACA;IACA,IAAIA,IAAI,CAAC,CAAC,CAAC,KAAK,GAAG,EAAE;MACnB,OAAOA,IAAI,CAACC,KAAK,CAAC,GAAG,CAACC,MAAM,CAAC;IAC/B;IACA;IACA;IACA;IACA;IACA;IACA,OAAO,KAAK,GAAGF,IAAI;EACrB;AACF"}