Coder Legion - Recent posts tagged excel

Distinguishing Excel Subtotal Rows from Detail Rows in SSAS Multidimensional MDX

Sun, 26 Jul 2026 08:09:44 +0000

When connecting Excel PivotTables to an SSAS Multidimensional cube, distinguishing whether a cell belongs to an individual detail row or an aggregated subtotal row is a common challenge.

How to Achieve It

To identify row context dynamically in MDX, you leverage the current hierarchy member's position relative to its siblings or descendants.

Utilize ISLEAF() function to evaluate if the current member in the attribute hierarchy is at the lowest grain.

Leverage COUNT() with .CHILDREN or .DESCENDANTS to check if the current context represents a set of members rather than a single attribute instance.

Combine logic with SCOPE statements in the cube's MDX Script to override measure behavior specifically for aggregate levels versus detail levels.

Problems You Will Encounter
Implementing conditional logic based on aggregation context introduces specific hurdles:

Subtotal Context Discrepancy: Excel PivotTables do not always query the hierarchy explicitly at the root level; subtotal rows send set-based queries that can evaluate as multiset aggregations rather than standard hierarchy parents.

Performance Degradation: Applying procedural functions like ISLEAF() or COUNT() inside calculated measures forces cell-by-cell evaluation, bypassing the SSAS formula engine cache and slowing down PivotTable refresh rates.

Visual Totals Confusion: When filters or slicers are applied in Excel, a subtotal row might evaluate to a single member context, leading MDX script logic to misidentify a subtotal as a detail row.

How We Solve This Problem
The most robust solution uses the ISLEAF() predicate paired with explicit SCOPE isolation or checking the .CURRENTMEMBER depth.

Apply direct leaf-level validation:

Code snippet
CASE

WHEN [Product].[Category].CURRENTMEMBER.ISLEAF 
THEN [Measures].[Detail Value]
ELSE [Measures].[Subtotal Value]

END
Use SCOPE statements for optimal performance:

Code snippet
/ Apply default subtotal logic /
SCOPE([Measures].[MyMeasure]);

THIS = [Measures].[Subtotal Value];

END SCOPE;

/ Override strictly for leaf-level detail rows /
SCOPE([Measures].[MyMeasure], [Product].[Category].[Category].MEMBERS);

THIS = IF([Product].[Category].CURRENTMEMBER.ISLEAF, [Measures].[Detail Value], [Measures].[Subtotal Value]);

END SCOPE;
Filter out multi-select slicer edge cases: Check [Hierarchy].CURRENTMEMBER IS [Hierarchy].[All] or evaluate .LEVEL.ORDINAL to guarantee the calculation knows exact depth within the hierarchy.

Sumita
Web Developer

php_excel 2.0: The C Extension for Excel That PHP Should Have Had All Along

Mon, 04 May 2026 19:48:44 +0000

PHP processes more Excel files than any language except maybe Python. Payroll exports, inventory imports, financial reports, data migrations. If your business runs on spreadsheets (and it does), your PHP app touches them constantly.

The standard approach is PhpSpreadsheet: a pure-PHP library that parses XML, builds an in-memory object graph, and promptly devours your server's RAM. It works fine for small files. It falls apart the moment someone uploads a 50,000-row export from SAP. (Don't ask me how I know. )

php_excel takes a different path. It's a PHP extension that wraps LibXL, a commercial C/C++ library purpose-built for reading and writing Excel files. Unlike most alternatives, LibXL handles both modern xlsx (Office 2007+) and the legacy xls binary format (Excel 97-2003), so you don't need separate codepaths for old and new files.

Instead of parsing XML in userland PHP, every cell read and write is a single C function call. In my benchmarks it's 7-10x faster than PhpSpreadsheet, and its memory footprint stays flat while PhpSpreadsheet's climbs past a gigabyte.

Version 2.0 shipped on April 5, 2026. It's the first major release in a long while, and it brings the extension fully into modern PHP.

What Changed in 2.0

The last official release (1.0.2) dates back to 2016. There was an unreleased 1.0.3 with PHP 7 support contributed by community members a few years later, but it never shipped. PHP has changed a lot since then. 2.0 is a ground-up modernization:

PHP 8.3 is the minimum version. Full support for 8.4, 8.5, and the development master branch. The extension builds and tests clean against all four, with zero warnings. On the LibXL side, the minimum is 4.6.0 (released over a year ago), with support up to the latest 5.1.0. I gate newer LibXL features at compile time: you get everything your installed version supports, and the extension still builds clean against 4.6.0.

2.0 adds six new classes to the existing six:

ExcelRichString: mixed-font text in a single cell (bold the header, italicize the footnote)
ExcelFormControl: checkboxes, dropdowns, spinners, buttons, and other form widgets
ExcelConditionalFormat / ExcelConditionalFormatting: conditional formatting rules and their application to cell ranges
ExcelCoreProperties: workbook metadata (title, author, creation dates, categories)
ExcelTable: structured table support for xlsx

I added methods across every existing class. ExcelBook now handles rich strings, conditional formats, VBA removal, DPI awareness, and picture-as-link support. ExcelSheet got pixel-based column/row sizing, tab colors, active cell management, selection ranges, form controls, data validation, and structured tables.

Every parameter and return type now has proper arginfo. That's 399 typed parameters and 277 typed return values, which means IDE autocompletion and static analysis tools actually work with the extension.

I also cleaned up the internals. Constructors now throw exceptions on error instead of silently returning false. I fixed several use-after-free bugs, null pointer dereferences, and memory leaks, the kind of issues that only surface under heavy load or with AddressSanitizer enabled. Serialization is disabled on all classes (serializing a file handle was never going to end well). The full list is in the ChangeLog.

Why a C Extension?

PHP's process-per-request model means every request starts from scratch. When PhpSpreadsheet opens a 100,000-row file, it parses the underlying XML with SimpleXML (DOM-based, so the entire XML tree lives in memory), then builds a Cell object for every cell with coordinate indexes, style references, and type metadata. In my benchmarks, PhpSpreadsheet 5.5 used about 1,066 MB to load 2 million cells, roughly 0.5 KB per cell for the object graph alone. That's already over a gigabyte for a single 100,000-row sheet. Add formatting, and it climbs further.

LibXL does the same work in optimized C/C++. The XML parsing, ZIP decompression, and cell storage all happen in native code. The extension itself is a thin translation layer: it takes PHP zvals, converts them to C types, calls the LibXL function, and converts the result back. The overhead per cell is a few hundred nanoseconds.

LibXL still uses real memory on the C heap for its internal workbook structures, so this isn't a free lunch. But it uses that memory more efficiently than PhpSpreadsheet's PHP object graph, and it's close to an order of magnitude faster.

Benchmarks

I ran these on PHP 8.4.19 (release build, NTS) against PhpSpreadsheet 5.5.0. Each test writes or reads a mix of integers, floats, and strings across 20 columns. Same data, same machine, measured with hrtime().

Here's the php_excel write test:

$book = new ExcelBook(null, null, true); // xlsx mode
$sheet = $book->addSheet('Bench');

for ($r = 1; $r <= $rows; $r++) {
    for ($c = 0; $c < $cols; $c++) {
        if ($c % 3 === 0) {
            $sheet->write($r, $c, $r * $cols + $c);        // integer
        } elseif ($c % 3 === 1) {
            $sheet->write($r, $c, "Row{$r}_Col{$c}_Text");  // string
        } else {
            $sheet->write($r, $c, $r * 1.5 + $c * 0.3);    // float
        }
    }
}
$book->save($outFile);

And the PhpSpreadsheet equivalent:

$spreadsheet = new Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();

for ($r = 1; $r <= $rows; $r++) {
    for ($c = 1; $c <= $cols; $c++) {
        if (($c - 1) % 3 === 0) {
            $sheet->setCellValue([$c, $r], $r * $cols + $c);
        } elseif (($c - 1) % 3 === 1) {
            $sheet->setCellValue([$c, $r], "Row{$r}_Col{$c}_Text");
        } else {
            $sheet->setCellValue([$c, $r], $r * 1.5 + $c * 0.3);
        }
    }
}
$writer = new Xlsx($spreadsheet);
$writer->save($outFile);

Write results (time / total process memory via VmPeak):

Rows	Cells	php_excel	PhpSpreadsheet	Speed
1,000	20K	0.05s / 85 MB	0.45s / 162 MB	10x
10,000	200K	0.55s / 153 MB	4.59s / 282 MB	9x
50,000	1M	2.72s / 508 MB	24.7s / 790 MB	9x
100,000	2M	5.37s / 908 MB	51.1s / 1,415 MB	10x

All memory figures are total process RSS (VmPeak from /proc/self/status), including the C heap. LibXL does use real memory for its internal structures, so php_excel isn't "free" on that front. But even counting everything, it uses 40-65% of what PhpSpreadsheet needs and finishes 9-10x faster.

One practical detail: PHP's memory_get_peak_usage() reports 2 MB for php_excel throughout, versus 1,254 MB for PhpSpreadsheet at 100K rows. LibXL allocates on the C heap, invisible to PHP's memory manager and memory_limit. If your PHP-FPM pool has a 128 MB memory_limit, PhpSpreadsheet will OOM on a 10K-row file. php_excel won't.

Read results (time / total process memory via VmPeak):

Rows	Cells	php_excel	PhpSpreadsheet	OpenSpout
1,000	20K	0.05s / 83 MB	0.39s / 175 MB	0.16s / 126 MB
10,000	200K	0.47s / 144 MB	3.74s / 578 MB	1.48s / 130 MB
50,000	1M	2.60s / 422 MB	20.1s / 2,317 MB	8.00s / 130 MB
100,000	2M	5.19s / 767 MB	40.8s / 4,501 MB	16.6s / 130 MB

Three different profiles. php_excel is fastest but uses memory proportional to the file (LibXL loads the whole workbook). PhpSpreadsheet is slowest and its memory explodes, 4.5 GB for 100K rows. OpenSpout streams row by row, so memory stays flat at 130 MB regardless of size, but it's 3x slower than php_excel.

To be fair to PhpSpreadsheet: it's the most feature-complete pure-PHP Excel library. If you don't need a C extension and your files stay under a few thousand rows, it works fine. Past that, it doesn't.

OpenSpout fills a different niche. It can't do random cell access, conditional formatting, formulas, rich text, form controls, or xls format. If your workload is "read CSV-like data from xlsx," it's a good free choice. If you need actual Excel features, it won't help.

php_excel gives you C library speed with the full Excel feature set. The tradeoff: LibXL requires a commercial license, and installing a C extension takes more effort than composer require. Whether that tradeoff makes sense depends on your workload. If you're generating a 200-row report once a day, PhpSpreadsheet is fine. If you're processing bulk imports, financial data, or anything where users upload files of unpredictable size, the C extension pays for itself quickly.

Code Examples

Creating a workbook and writing data:

$book = new ExcelBook();
$sheet = $book->addSheet('Sales Q1');

// Headers
$boldFont = new ExcelFont($book);
$boldFont->bold(true);
$headerFormat = new ExcelFormat($book);
$headerFormat->font($boldFont);

$headers = ['ID', 'Date', 'Customer', 'Amount', 'Status'];
foreach ($headers as $col => $header) {
    $sheet->write(1, $col, $header, $headerFormat);
}

// Data rows
$data = [
    [1001, '2026-03-15', 'Acme Corp', 15750.00, 'Paid'],
    [1002, '2026-03-16', 'Globex Inc', 8200.50, 'Pending'],
    [1003, '2026-03-17', 'Initech', 42000.00, 'Paid'],
];

$dateFormat = new ExcelFormat($book);
$dateFormat->numberFormat(ExcelFormat::NUMFORMAT_DATE);

$row = 2;
foreach ($data as $record) {
    $sheet->write($row, 0, $record[0]);
    $sheet->write($row, 1, strtotime($record[1]), $dateFormat, ExcelFormat::AS_DATE);
    $sheet->write($row, 2, $record[2]);
    $sheet->write($row, 3, $record[3]);
    $sheet->write($row, 4, $record[4]);
    $row++;
}

// Summary formula
$sheet->write($row, 3, '=SUM(D2:D4)');

$book->save('sales-q1.xlsx');

Reading an uploaded file:

$book = new ExcelBook();
$book->loadFile($_FILES['report']['tmp_name']);

$sheet = $book->getSheet(0);
$lastRow = $sheet->lastFilledRow();
$lastCol = $sheet->lastFilledCol();

for ($row = $sheet->firstFilledRow(); $row <= $lastRow; $row++) {
    $rowData = $sheet->readRow($row, 0, $lastCol);
    // process $rowData
}

Rich text in a single cell:

$book = new ExcelBook();
$sheet = $book->addSheet('Notes');

$richString = $book->addRichString();

$boldFont = new ExcelFont($book);
$boldFont->bold(true);

$richString->addText('Important: ', $boldFont);
$richString->addText('Review before end of quarter.');

$sheet->writeRichStr(1, 0, $richString);
$book->save('notes.xlsx');

Working with conditional formatting:

$book = new ExcelBook();
$sheet = $book->addSheet('Metrics');

// Write some data
for ($row = 1; $row <= 20; $row++) {
    $sheet->write($row, 0, rand(0, 100));
}

// Highlight cells above 75 in green
$cf = $book->addConditionalFormat();
$cf->font()->bold(true);
$cf->font()->color(ExcelFont::COLOR_GREEN);

$formatting = $sheet->addConditionalFormatting();
$formatting->addRange(1, 0, 20, 0);
$formatting->addRule(
    ExcelConditionalFormat::CELLIS,
    $cf,
    ExcelConditionalFormat::OPERATOR_GREATERTHAN,
    '75'
);

$book->save('metrics.xlsx');

Installation

Linux / macOS

First, get LibXL 4.6.0 or newer from libxl.com. It's a commercial library; there's a trial version that works without a license key (limited to ~300 cells and row 0 is inaccessible).

The easiest path is PIE (PHP Installer for Extensions), the official PECL replacement. I added PIE support as part of 2.0:

pie install iliaal/php-excel \
  --with-libxl-incdir=/opt/libxl/include_c \
  --with-libxl-libdir=/opt/libxl/lib64

Or build from source:

git clone https://github.com/iliaal/php_excel.git
cd php_excel
phpize
./configure --with-excel \
  --with-libxl-incdir=/opt/libxl/include_c \
  --with-libxl-libdir=/opt/libxl/lib64
make
sudo make install

Then add to your php.ini:

extension=excel.so

Make sure the LibXL shared library is in your linker path. Either install it to a standard location or set LD_LIBRARY_PATH:

echo "/opt/libxl/lib64" | sudo tee /etc/ld.so.conf.d/libxl.conf
sudo ldconfig

Windows

Pre-built DLLs for PHP 8.3 and 8.4 (both x64 and x86, TS and NTS) are attached to every GitHub release. Download the DLL matching your PHP version and architecture, drop it into your ext directory, and add to php.ini:

extension=excel

You'll also need libxl.dll from the LibXL Windows distribution placed somewhere in your system PATH, or in the same directory as php.exe.

License Key Configuration

If you have a LibXL license, store the credentials in php.ini rather than your source code:

[excel]
excel.license_name="Your Name"
excel.license_key="your-license-key-here"

The extension reads these automatically. Pass null for the license parameters in the ExcelBook constructor and they'll be picked up from the ini settings.

The extension is open source under the PHP-3.01 license. LibXL itself requires a commercial license for production use.

Source on GitHub. Issues, PRs, and stars welcome.

Excel Exporter

Fri, 09 Jan 2026 12:25:29 +0000

Excel / VBA folks – quick share

I’ve released a small Windows tool I built out of real-world frustration:

Excel Exporter.

It does one thing well:

exports Excel code objects (modules, classes, forms) from Excel files into clean files on disk.

https://lnkd.in/dkyAfqsj

It comes as Free and Pro Edition

About the Free Edition

The Free Edition is fully functional for single Excel files:

Works with all common Excel formats (.xls, .xlsx, .xlsm, .xlsb, .xla, .xlam, etc.)

Exports clean .bas, .cls, .frm files

Organizes everything into a folder named after the workbook

Optional ZIP export

If you work with one Excel file at a time, the free version is honestly enough.

What the PRO adds (and why it exists)

The PRO edition doesn’t unlock “power” — it unlocks convenience:

Batch export from folders (lots of Excel files at once)

Command-line (CLI) support for automation

This is useful if you:

Maintain many Excel/VBA files

Need to audit legacy systems

Want to integrate exports into scripts or CI jobs

Example CLI usage (PRO):

ExcelExporter.exe -file "c:\Projects\MyExcel.xlsm" -modules -classes -forms

If you’re interested in the PRO version:

Email me at Emails are not allowed (P.S. Pro edition $5)

Payments via PayPal or Wise.

I’ll send you the PRO build and (optionally) add you to the private GitHub repo.

If not — the Free Edition is open-source and works perfectly for single files.

Sharing in case it helps someone dealing with VBA-heavy Excel systems (we all know how painful those can be).

[Review] 20250620: The Plan to Supersede Excel

Fri, 20 Jun 2025 13:50:46 +0000

Soon enough, Divooka is almost here. Let's go back to the problem that got us started: practical data analytics at scale.

We're not trying to completely replace Excel. Excel serves its purposes extremely well, and we envision a world where tools are more specialized depending on the needs. On the other hand, many of the problems Divooka aims to solve - particularly in data analytics - stem from overuse or misuse of Excel in situations it was never designed for. That's why Excel naturally becomes a benchmark for evaluating how well Divooka addresses these challenges - and in turn, how effectively Divooka can substitute for Excel in those contexts.

In general, the future we're building toward is one where people only use Excel occasionally - for working with legacy systems or exchanging files with external clients. For all other practical, internal, and repeatable analytical tasks, organizations and individuals shouldn't have to open Excel at all. That's the vision for Divooka in the data analytics space.

P.S. If you're wondering why we compare ourselves to Excel when talking about "data analytics" rather than Python - it's because we're focusing on where actual work gets done by everyday professionals in finance, retail, consulting, etc. - outside of data scientists and machine learning engineers, who typically work within well-defined infrastructures or theoretical environments.

Overview

Excel offers the following main functionalities and use cases:

Using worksheets/workbooks as informal databases – enabling data entry, filtering, etc.
Applying formulas for analytics – calculating sums, performing aggregates, lookups.
Plotting and reporting – generating charts and formatted reports.
Automating results and, to some extent, content – via templates for repeated use.

A Note on Learning

Some claim Excel is easier to learn than Python or Divooka. In our experience, that perception usually comes from people who've been using Excel for 10+ years. That certainly wasn't my experience when I first tried to learn it - by then, I was already an experienced programmer.

Excel has a lot of quirks. Fortunately, it also has a wealth of online resources - forums, tutorials, and StackOverflow answers - that help users troubleshoot specific needs quickly. But that doesn't necessarily make it easier to learn.

Meanwhile, its automation and extension system (VBA, VSTO) and DOM model are far from elegant. They can be powerful - but they're also idiosyncratic, outdated, and hard to scale or maintain.

Identifying Veteran Use

For veteran users - those who've worked in finance, consulting, banking, or retail for over a decade - it's crucial to identify what matters most to them so we don't waste time trying to rebuild everything from scratch.

For these professionals, usually in management roles, key priorities tend to be:

Simple data entry
Basic formulas (especially VLOOKUP and IF logic) and pivot tables
Minimal plotting
Extensive styling, including conditional formatting

Veterans rarely write VBA or build complex automated spreadsheets themselves - that's what interns and junior staff are usually tasked with.

The Solution Plan

Divooka already outperforms Excel in areas like analytics and automation (points 3 and 4), but matching Excel's GUI experience for basic data entry and formulas remains a challenge.

The Challenges

The problem can be broken down into two fronts:

We must provide a familiar interface and usage pattern - even though Divooka is not Excel - to reduce resistance from long-time Excel users.
Divooka is a visual programming language with its own design principles. While we want to be similar to Excel where needed, we must stay true to what makes Divooka powerful and unique.

The Approaches

To address the GUI/database usage pattern, we're exploring a few possible approaches:

Create a custom visual node that replicates the structure of a standard Excel worksheet - though it might look more like a clean, modern take similar to Apple Numbers.
Encourage users to adopt API-driven or externalized databases and foster a mindset of separating data, computation, and presentation. While we offer SQL and database API integration out of the box, we also recognize that many users resist this - even if they're already managing convoluted Excel formulas.
On that note, there are two directions we're exploring:
- Provide a visual interface (like MySQL Workbench) for common database operations.
- Offer a high-level, node-based API that avoids manual SQL writing, while gently encouraging users to become more familiar with what's happening under the hood.

A Combined Use Case

The most common (and most problematic) Excel use case is when people combine:

Data entry,
Basic automated calculations,
Fancy styling,
Plots and form updates for reporting purposes.

This is where Excel shines - and also where it often gets abused. It enables incredibly compact and self-contained workflows: enter numbers, add formulas, apply some styling - and voilà, you have a polished report.

But this convenience comes at a cost: poor scalability, maintainability issues, and a lack of clear separation of concerns. A single cell can simultaneously serve as a data source, a computed result, and a styled report element. This makes downstream changes, automation, and collaboration extremely hard.

The traditional software engineering solution is seen in the web: HTML (structure), CSS (style), and JavaScript (logic). By clearly separating concerns, we maintain flexibility and clarity. So what if creating an HTML/CSS/JS-based dashboard was as easy as building an Excel sheet? That's one possible angle - and something Divooka could eventually support through node APIs or higher-level content editors.

But that's not the most elegant path forward.

The Real Solution

The better question to ask is: what is the actual end goal?

People want to build interactive dashboards or reports that auto-update, look professional, and live within a single workspace where they can easily edit data, adjust formulas, and customize visuals - all while staying clean and maintainable.

Wait a second - doesn't that sound like App Mode in Neo?

(Screenshot coming soon when the time is right.)

Conclusion

Divooka was never about "replacing Excel" outright. That was never the goal - and still isn't. What we set out to solve was broader and deeper: making practical, scalable data analytics accessible to professionals who are otherwise stuck with brittle, overextended workflows. Excel simply happens to be the dominant tool in that space, so it naturally became both our benchmark and our foil.

In a sense, replacing Python is an easier problem - just design a better language, with better libraries and ecosystem. Julia is doing that, so are many others. When we started tackling "The Excel Problem," it felt vague and enormous. We only had instincts: "There must be a better way," and "Visual programming, like Divooka, seems right." Back then, we didn't yet see the full shape of the solution.

But as Divooka matures, as our libraries evolve, and as our design principles solidify, the picture becomes clearer.

It's becoming evident that:

Data entry can be streamlined through a combination of high-level APIs and dedicated GUIs.
Dedicated graphical editors are not just useful - they're the future. We'll share more on this next year.
Divooka's graph-based mindset is not only powerful but practical. Neo will serve as the reference implementation and the litmus test for what a modern visual programming platform can achieve.

Of course, there are still many UX and ergonomics problems to solve - and we must proceed with care.

But we're getting close.

Resources

App Mode

How to Create a Date Table in Power Query

Fri, 18 Apr 2025 10:43:44 +0000

A Date table is needed for analysis in Power BI because it helps organize and analyze data by date. As the name implies, it enables you to create a calendar (date information) that works for the analysis you want to carry out. i.e weekday, month & year analysis.

Why is Date Table important in Power BI?

It can be used for a variety of purposes, including:

Filtering data: It can filter data by specific date attributes, such as month, quarter, year, or weekday.
Creating visuals: It helps in creating visuals with dynamic periods, such as the current quarter or month.
Comparing data: It helps in comparing data over time, such as from
one year to the next or from one month to the next.
Using DAX time intelligence functions: You can use DAX time
intelligence functions that wouldn’t normally work without a date
table.
Optimizing data model: When working with large data sets, a separate
date table can help you establish associations between your data
tables and the date table. This can help you boost productivity,
cross-functional reporting, and optimize your data model.
Standardizing date formatting: It can help create standardized date
formatting. Improving data modeling: It can improve data modeling.

You can check out BI Samurai for more explanation on why you need a date table

A date table can be created in Power Query or DAX. In this article, you will be creating your date table in Power Query.

Creating a Date Table in Power Query

Open Power Query, Home>>Transform Data

Click on the New Source dropdown and Create a blank query.

In the formula bar, write an M code to compute the date list.

= List.Dates(#date(2025,1,1), 365, #duration(1,0,0,0))
List.Dates(start as date, count as number, step as duration)

List.Dates: the list.date function take 3 arguments (parameters)
start as date: the date you want to start from
count as number: the number you want it to count from the start date
step as duration: the number of days, hours, minutes or seconds you
want to count from the start date.

In the code above, the start date is the 1st of January 2025, then count 365 of the duration arguments. The #duration arguments have (1,0,0,0) which translates to 1 day, 0 hour, 0 minute, and 0 second.

In this case, the date will start from 2025–01–01 and count 365 days from the start date, and that’s what will return in your query.

Once a list column has been created, right-click on the column and convert the list to a table (that’s what Power Query allows transformation on).

Leave delimiter as None. Then click OK

NB: if you have data that contains a list of items i.e. [dogs, cats, birds] etc. The delimiter in this scenario is the comma separating those items, and if there is a row that doesn’t have a list value, how it will handle it is the second option in the prompt box.

Now it’s in table format. (tabular structure)

Change the data type and rename the column, go to Add Column>>Date and start selecting other date parameters to form the calendar table.

NB: Make sure the Date column is selected before adding a new column.

You can get the scripts to replicate yours

let
Source = List.Dates(#date(2025,1,1), 365, #duration(1,0,0,0)),
#"Converted to Table" = Table.FromList(Source, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
#"Changed Type" = Table.TransformColumnTypes(#"Converted to Table",{{"Column1", type date}}),
#"Renamed Columns" = Table.RenameColumns(#"Changed Type",{{"Column1", "Date"}}),
#"Inserted Year" = Table.AddColumn(#"Renamed Columns", "Year", each Date.Year([Date]), Int64.Type),
#"Inserted Start of Year" = Table.AddColumn(#"Inserted Year", "Start of Year", each Date.StartOfYear([Date]), type date),
#"Inserted End of Year" = Table.AddColumn(#"Inserted Start of Year", "End of Year", each Date.EndOfYear([Start of Year]), type date),
#"Inserted Month" = Table.AddColumn(#"Inserted End of Year", "Month", each Date.Month([Date]), Int64.Type),
#"Inserted Month Name" = Table.AddColumn(#"Inserted Month", "Month Name", each Date.MonthName([Date]), type text),
#"Inserted Days in Month" = Table.AddColumn(#"Inserted Month Name", "Days in Month", each Date.DaysInMonth([Date]), Int64.Type),
#"Inserted Start of Month" = Table.AddColumn(#"Inserted Days in Month", "Start of Month", each Date.StartOfMonth([Date]), type date),
#"Inserted End of Month" = Table.AddColumn(#"Inserted Start of Month", "End of Month", each Date.EndOfMonth([Date]), type date),
#"Inserted Quarter" = Table.AddColumn(#"Inserted End of Month", "Quarter", each Date.QuarterOfYear([Date]), Int64.Type),
#"Inserted Start of Quarter" = Table.AddColumn(#"Inserted Quarter", "Start of Quarter", each Date.StartOfQuarter([Date]), type date),
#"Inserted End of Quarter" = Table.AddColumn(#"Inserted Start of Quarter", "End of Quarter", each Date.EndOfQuarter([Date]), type date),
AddColumns = Table.AddColumn(#"Inserted End of Quarter", "Month Name Short", each Date.ToText([Date], "MMM"), type text),
AddMonthAndDay = Table.AddColumn(AddColumns, "Month & Day", each Date.ToText([Date], "MMM") & " " & Text.From(Date.Day([Date])), type text),
AddMonthAndYear = Table.AddColumn(AddMonthAndDay, "Month & Year", each Date.ToText([Date], "MMM") & "-" & Date.ToText([Date], "yyyy"), type text),
AddYearMonthNum = Table.AddColumn(AddMonthAndYear, "Year Month Num", each Number.FromText(Date.ToText([Date], "yyyyMM")), Int64.Type),
AddYearMonthName = Table.AddColumn(AddYearMonthNum, "Year Month Name", each Date.ToText([Date], "yyyy-MMM"), type text),
#"Inserted Day" = Table.AddColumn(AddYearMonthName, "Day", each Date.Day([Date]), Int64.Type),
#"Inserted Day of Week" = Table.AddColumn(#"Inserted Day", "Day of Week", each Date.DayOfWeek([Date]), Int64.Type),
#"Inserted Day of Year" = Table.AddColumn(#"Inserted Day of Week", "Day of Year", each Date.DayOfYear([Date]), Int64.Type),
#"Inserted Start of Day" = Table.AddColumn(#"Inserted Day of Year", "Start of Day", each Date.StartOfDay([Date]), type date),
#"Inserted End of Day" = Table.AddColumn(#"Inserted Start of Day", "End of Day", each Date.EndOfDay([Date]), type date),
#"Inserted Day Name" = Table.AddColumn(#"Inserted End of Day", "Day Name", each Date.DayOfWeekName([Date]), type text)
in
#"Inserted Day Name"

Happy Querying!!! Now you have a date table to use for your analysis.

If you encounter any difficulties or have any questions, feel free to reach out through the comment box. You can connect with me on Twitter and LinkedIn where I share my daily activities about data analytics, personal experience, and career life.