DEV Community: Anthony Kibet

Why Statistics Is the Backbone of Data Science

Anthony Kibet — Sat, 22 Aug 2026 18:30:18 +0000

Statistics isn't a supporting subject in data science, it's the thing that makes the "science" part of data science actually mean something.

Code Gives You Numbers. Statistics Tells You What They Mean.

Anyone can write a few lines of code to calculate an average, plot a chart, or run a model. What statistics adds is the ability to know whether any of that actually means anything. Is a 3% increase in sales real, or just random noise? Is that correlation between two variables meaningful, or a coincidence dressed up as a pattern? Without a statistical foundation, it's easy to mistake noise for signal, and confidently draw the wrong conclusion.

This is really the core value statistics brings: it's the discipline of reasoning carefully under uncertainty, instead of just reacting to whatever the numbers seem to say on the surface.

Where Statistics Shows Up in the Data Science Workflow

Exploratory data analysis. Before any modeling happens, statistics is what helps you actually understand a dataset. Measures like mean, median, standard deviation, and distribution shape tell you what's typical, what's an outlier, and where your data might be skewed or messy.

Hypothesis testing. When a company wants to know if a new website design actually increases conversions, or if a new drug actually works better than a placebo, statistical hypothesis testing is what separates "it looks like it worked" from "we can say with reasonable confidence that it worked."

Sampling and inference. Data scientists rarely have access to an entire population's data. Statistics provides the tools to draw a sample, and then make defensible conclusions about the broader population from that smaller slice, along with an honest sense of how much uncertainty comes with that.

Model evaluation. Every machine learning model spits out predictions, but statistics is what tells you whether those predictions are actually good. Concepts like variance, bias, confidence intervals, and significance testing are what separate a model that works from one that just looks like it works on the surface.

A/B testing. This is statistics in its most visible business form. Comparing two versions of a product, email, or webpage isn't just about seeing which number is bigger, it's about determining whether the difference is statistically meaningful or just random fluctuation.

Why This Matters More as Machine Learning Gets Easier

Ironically, as machine learning tools get more accessible, the need for solid statistical thinking goes up, not down. It's become genuinely easy to import a model, fit it to data, and get predictions out the other end, all without deeply understanding what's happening in between. That's exactly where statistics becomes protective.

Someone with a strong statistical foundation understands why a model might be overfitting, why a certain metric is misleading for an imbalanced dataset, or why a "95% accurate" model might actually be nearly useless depending on the context. Without that grounding, it's dangerously easy to build something that performs well on paper and fails badly in the real world.

Statistics Protects Against Misleading Conclusions

A huge part of a data scientist's job isn't building models, it's making sure the conclusions being drawn from data are actually justified. Statistics is full of built-in guardrails for this: understanding p-values and their limitations, recognizing confounding variables, knowing the difference between correlation and causation, and being aware of common biases in how data is collected.

Without these guardrails, it's easy to fall into traps that feel intuitive but are statistically wrong, like assuming a relationship between two variables means one causes the other, or trusting a small sample size as if it represents the whole population.

The Takeaway

Data science borrows tools from computer science, but its judgment comes from statistics. Code is what lets you process and manipulate data at scale, but statistics is what lets you trust, question, and correctly interpret what that data is actually telling you. A data scientist without statistical grounding can still produce charts and models, but a data scientist with it can tell you whether those charts and models deserve to be believed in the first place. That distinction is, in a lot of ways, the entire point of the field.

Linux in Real-World Data Engineering

Anthony Kibet — Fri, 21 Aug 2026 11:01:13 +0000

Linux is the one most people never see at all, even though it's running underneath almost everything in modern data engineering. Servers, databases, pipelines, cloud infrastructure: a huge share of it runs on Linux, quietly, in the background. For anyone moving from writing scripts to actually engineering data systems, understanding Linux stops being optional pretty quickly.

Why Data Engineering Runs on Linux

Linux dominates this space for a few practical reasons. It's stable, it's free and open-source, and it's built to run unattended for long stretches without needing a GUI or constant babysitting. Cloud providers like AWS, Google Cloud, and Azure run the overwhelming majority of their infrastructure on Linux, which means the pipelines, databases, and servers data engineers build almost always live on it too.

It's also the default environment for the tools data engineers rely on daily. Things like Apache Spark, Airflow, Kafka, and PostgreSQL were built with Linux environments in mind, and documentation, community support, and production setups almost always assume you're working in one.

Real-World Scenarios Where Linux Shows Up

Hosting databases and data warehouses. Systems like PostgreSQL, MySQL, and MongoDB are commonly deployed on Linux servers, whether that's an on-premises machine or a cloud instance. Data engineers regularly SSH into these servers to manage configurations, check logs, or troubleshoot performance issues.

Running scheduled data pipelines. ETL and ELT jobs, the processes that extract, transform, and load data between systems, are often scheduled and executed on Linux machines using tools like cron jobs or orchestration platforms like Airflow, which itself typically runs on Linux.

Cloud infrastructure and containers. Most cloud virtual machines default to a Linux distribution, and container technologies like Docker are built directly on Linux's architecture. A data engineer spinning up a containerized pipeline is, under the hood, working with Linux whether they realize it or not.

Log monitoring and debugging. When a pipeline fails at 2 a.m., the first stop is usually a Linux server's log files. Being comfortable navigating the command line to find, filter, and read logs is often the difference between a five-minute fix and a multi-hour outage.

Automating repetitive tasks. Shell scripting lets data engineers automate things like moving files, cleaning up old logs, or kicking off a data job on a schedule, without needing a full application to do it.

Skills and Tools That Do the Heavy Lifting

The command line (Bash). This is the foundation. Navigating directories with cd and ls, moving and copying files with mv and cp, and managing permissions with chmod are everyday actions, not occasional ones. A huge share of data engineering work happens through a terminal rather than a graphical interface.

grep and text processing. Searching through massive log files or datasets for specific patterns is a constant need. grep lets you filter for a specific error message across thousands of lines almost instantly, and pairing it with tools like awk and sed allows for quick text transformations directly from the command line.

Piping and redirection. The | operator lets you chain commands together, feeding the output of one directly into another. For example, listing files, filtering them by name, and counting the results, all in a single line, without writing a script.

Cron jobs. Cron is Linux's built-in job scheduler, and it's the classic way to automate recurring tasks, like running a data pipeline every night at midnight or cleaning up temporary files every week. A single line in a crontab file can replace a task someone would otherwise have to remember to do manually.

File permissions and ownership. Understanding chmod and chown matters more than it seems, especially in shared environments where multiple services or team members interact with the same files. Getting permissions wrong can silently break a pipeline or expose sensitive data.

SSH. Secure Shell is how engineers connect to remote servers to manage them. Almost all cloud-based data work involves SSHing into a machine at some point, whether to check on a job, install software, or debug an issue directly.

Environment variables and .env files. Storing credentials and configuration outside of actual code is a standard practice, and Linux environments make this straightforward to manage, keeping sensitive information like database passwords out of version control.

How It All Comes Together

A typical real-world scenario might look like this: a data pipeline is scheduled to run every night via a cron job on a Linux server. It pulls data from an API, and if something goes wrong, the engineer SSHes into the server, uses grep to scan the log files for the specific error, checks file permissions to make sure the script had access to what it needed, and pushes a fix, all without ever touching a graphical interface. None of these steps are exotic on their own, but together they represent a huge share of what keeps real-world data systems running smoothly behind the scenes.

The Takeaway

Linux doesn't get talked about the way flashy data tools do, but it's the environment almost everything else sits on top of. Learning the command line, basic scripting, and how to navigate a Linux system isn't a side skill for data engineers, it's close to a prerequisite. The pipelines, databases, and cloud infrastructure that modern data work depends on are, more often than not, quietly running on Linux the entire time.

Understanding Data Modeling in Power BI

Anthony Kibet — Thu, 20 Aug 2026 18:52:43 +0000

Data modeling is the part of Power BI that separates people who can build a chart from people who can build a dashboard that actually holds up. It's less flashy than a slick visual, but it's the foundation everything else sits on. Get it wrong, and your numbers quietly lie to you. Get it right, and the rest of the report practically builds itself.

What Data Modeling Actually Is

At its core, data modeling is the process of organizing your data tables and defining how they relate to each other so that a tool like Power BI can pull accurate, consistent answers out of them. Instead of dumping every column into one giant table, you break data into logical, connected pieces, then tell Power BI how those pieces fit together.

Think of it like organizing a filing cabinet. You could throw every document into one folder, but finding anything would be painful, and duplicates would pile up fast. Instead, you create separate folders (tables) for customers, orders, and products, then create a system for cross-referencing them. That cross-referencing system is essentially what relationships do in Power BI.

Good data modeling makes reports faster, calculations more accurate, and the whole system easier to maintain as your data grows.

All Six SQL Joins, With Real-Life Examples

Joins are how you combine rows from two or more tables based on a related column. Even though Power BI handles a lot of this visually through relationships, understanding joins at the SQL level makes everything about Power BI's relationship system click faster.

1. INNER JOIN — Returns only the rows that match in both tables.
Example: You have a Customers table and an Orders table. An inner join returns only customers who've actually placed an order, leaving out anyone who signed up but never bought anything.

2. LEFT JOIN (LEFT OUTER JOIN) — Returns everything from the left table, plus matching rows from the right table. Unmatched rows from the right table show up as null.
Example: Pulling all customers, even ones with zero orders, so you can identify inactive accounts. Customers without a matching order still appear, just with empty order details.

3. RIGHT JOIN (RIGHT OUTER JOIN) — The mirror image of a left join: everything from the right table, plus matches from the left.
Example: If you flip the query around and start from Orders, a right join back to Customers would return all orders, even ones where the customer record was somehow deleted, with blank customer info for those.

4. FULL OUTER JOIN — Returns everything from both tables, matched where possible, with nulls filling in the gaps on either side.
Example: Comparing a list of registered employees against a list of building badge swipes, to catch both employees who never badged in and badge swipes with no matching employee record.

5. CROSS JOIN — Returns every possible combination of rows between two tables, with no matching condition at all.
Example: Combining a list of 5 products with a list of 12 months to generate every product/month pairing, useful for building a complete forecasting template even before actual sales numbers exist.

6. SELF JOIN — A table joined to itself, useful when rows in a table reference other rows in that same table.
Example: An Employees table with a ManagerID column that refers back to another employee's ID. A self join lets you list each employee next to their manager's name, even though both live in the same table.

Power BI Relationships: Cardinality, Cross-Filter Direction, and Active vs. Inactive

Relationships are how Power BI replicates the effect of SQL joins, but instead of writing a join every time you query, you define the relationship once, and Power BI applies it automatically across your visuals.

Cardinality describes the type of relationship between two tables:

One-to-many (1:*) — the most common type. One row in a table (like Products) relates to many rows in another (like Sales). One product, many sales transactions.
Many-to-one (*:1) — the same relationship, just viewed from the other direction.
One-to-one (1:1) — each row in one table relates to exactly one row in another, like an Employees table and a separate EmployeeContactDetails table.
Many-to-many (:) — rows in both tables can relate to multiple rows in the other, like Students and Courses, where a student takes many courses and a course has many students.

Cross-filter direction controls which way filtering flows through the relationship:

Single direction — filtering flows one way only, typically from the "one" side to the "many" side. This is the default and the safest choice for most models.
Both (bidirectional) — filtering flows both ways. This can be useful in specific cases but often causes ambiguous filtering and performance issues if overused, so it's usually best used sparingly and intentionally.

Active vs. inactive relationships: Power BI only allows one active relationship between two tables at a time, shown as a solid line in the model view. Any additional relationship between the same two tables becomes inactive, shown as a dashed line, and won't apply automatically. Inactive relationships still exist and can be used deliberately inside a DAX formula using the USERELATIONSHIP function, which is exactly how role-playing dimensions get handled.

Fact Tables vs. Dimension Tables

This distinction is central to how Power BI models are structured.

Fact tables hold the measurable, numeric events of your business, things that happened: sales transactions, website visits, shipments. They tend to be long (lots of rows) and narrow (fewer columns), and they usually contain foreign keys linking out to dimension tables.

Dimension tables hold the descriptive context around those events: who, what, where, when. A Customers table, a Products table, and a Date table are all dimensions. They tend to be shorter in row count but wider in columns, full of descriptive attributes used for filtering and grouping.

Example: A Sales fact table might just have a date, a product ID, a customer ID, and a quantity sold. The Products dimension table then holds the product name, category, and price, so you're not repeating that information across thousands of sales rows.

Star, Snowflake, and Flat Table Schemas

Star schema is the gold standard for most Power BI models. A single fact table sits in the center, directly connected to multiple dimension tables around it, like points on a star. It's simple, fast, and easy for both Power BI and the people building reports to understand.

Snowflake schema takes the star schema a step further by normalizing dimension tables into additional related sub-tables. For example, instead of one flat Products table, you might split it into Products and a separate ProductCategories table. This reduces data duplication but adds complexity and can slow down performance, since Power BI has to traverse more relationships to pull the same information.

Flat table schema dumps everything into a single wide table, no separate fact or dimension tables at all. It's the simplest to look at, but it scales poorly, duplicates data constantly, and makes calculations messier as the dataset grows. It's generally something to avoid once a model gets beyond a very small, simple use case.

For most real-world Power BI projects, star schema is the recommended approach: fast, clean, and scalable.

Role-Playing Dimensions

A role-playing dimension is a single dimension table that logically applies to a fact table in more than one way. The classic example is a Date table.

Example: A Sales fact table might have an OrderDate, a ShipDate, and a DeliveryDate. All three dates logically relate back to the same Date dimension table, but Power BI only allows one active relationship between two tables at a time. So one relationship (say, to OrderDate) stays active, while the other two become inactive.

To actually use those inactive relationships, you write DAX measures using USERELATIONSHIP, explicitly telling a calculation which relationship to use for that specific measure, like calculating total sales by ship date instead of order date.

Common Modeling Mistakes (and How to Fix Them)

Using a flat, single-table model. It feels easier at first, but it causes duplicated data and messy calculations down the line. Fix: break the data into proper fact and dimension tables and connect them with relationships.

Overusing bidirectional filtering. It's tempting to set every relationship to "both" to avoid filtering issues, but this often creates ambiguous results and hurts performance. Fix: default to single-direction relationships, and only use bidirectional filtering when there's a clear, specific reason.

Creating many-to-many relationships unintentionally. This usually happens when a supposed "dimension" table actually has duplicate values in its key column. Fix: check for and remove duplicates in dimension tables, or build a proper bridge table if a true many-to-many relationship is unavoidable.

Missing or incomplete date tables. Relying on the dates buried inside a fact table instead of a dedicated date table limits your ability to do time intelligence calculations properly. Fix: build a dedicated Date table and mark it as a date table in Power BI.

Snowflaking unnecessarily. Normalizing dimensions when there's no real need adds complexity without much benefit. Fix: default to a star schema unless there's a specific storage or data integrity reason to snowflake.

Not marking active vs. inactive relationships intentionally. Letting Power BI pick relationships by default, without understanding which one is active, can silently produce wrong numbers on a report. Fix: review relationships in the model view and consciously decide which should be active, using USERELATIONSHIP in DAX for the rest.

Step-by-Step: Applying These Concepts in Power BI

Building a relationship between two tables

Open Power BI Desktop and go to the Model view (the icon on the left sidebar that looks like connected tables).
Drag a field from one table (usually the foreign key, like ProductID in the Sales table) onto the matching field in another table (ProductID in the Products table).
In the dialog that appears, confirm or adjust the cardinality (Power BI usually detects it automatically) and set the cross-filter direction.
Click OK. The relationship now appears as a line connecting the two tables in the model view.

Setting cardinality and cross-filter direction manually

In Model view, double-click an existing relationship line to open its settings.
Under Cardinality, choose the correct option (one-to-many, one-to-one, etc.) based on your data.
Under Cross-filter direction, choose Single or Both depending on your needs, defaulting to Single unless you have a specific reason otherwise.
Click OK to save.

Creating an inactive relationship for role-playing dimensions

Create the relationship as usual between your fact table and dimension table (for example, Sales[ShipDate] to Date[Date]).
If an active relationship already exists between these two tables through another column, Power BI will automatically make this new one inactive, shown as a dashed line.
To use it, go to a new measure in the Data or Report view and write a DAX formula using USERELATIONSHIP, for example: Sales by Ship Date = CALCULATE(SUM(Sales[Amount]), USERELATIONSHIP(Sales[ShipDate], 'Date'[Date]))

Building a star schema

Identify your fact table (the one with transactional, numeric data).
Identify your dimension tables (descriptive tables like Customers, Products, Date).
In Model view, connect each dimension table directly to the fact table using one-to-many relationships, avoiding chains where dimensions connect to other dimensions.
Arrange the tables visually with the fact table in the middle and dimensions around it, purely for clarity, though Power BI doesn't require this layout to function.

Creating and marking a proper Date table

Go to the Modeling tab and select New Table.
Use a DAX formula like Date = CALENDAR(DATE(2020,1,1), DATE(2026,12,31)) to generate a continuous date range.
Add extra columns as needed, like Year, Month, or Quarter, using DAX functions such as YEAR() and FORMAT().
Select the new table, go to the Table tools tab, and click Mark as date table, then select the date column.
Connect this table to your fact table's date columns as needed.

The Takeaway

Data modeling in Power BI isn't just a technical setup step, it's the difference between a report that gives trustworthy answers and one that quietly produces the wrong numbers with total confidence. Understanding joins, relationships, schema types, and common pitfalls gives you the foundation to build models that are accurate, fast, and easy to maintain as your data grows. Visuals get the attention, but the model underneath is what makes them worth trusting.

Excel in Real-World Data Analysis

Anthony Kibet — Wed, 19 Aug 2026 08:23:18 +0000

Why Excel Still Matters

Part of it is accessibility. Nearly every business, from a five-person startup to a multinational corporation, has Excel installed somewhere. It doesn't need a server, a coding environment, or a dedicated data team to get value out of it. Someone in finance, marketing, or operations can open a spreadsheet, drop in some numbers, and start finding answers within minutes.

The other part is flexibility. Excel isn't just a place to store data, it's a full workspace for cleaning, exploring, calculating, visualizing, and presenting it, all in one file. That combination is hard to beat for quick, everyday analysis, even in companies that also use heavier tools for larger-scale work.

Real-World Scenarios Where Excel Shows Up

Financial reporting and budgeting. Finance teams build monthly and quarterly reports in Excel constantly, tracking revenue, expenses, and variances against budget. Formulas handle the math, formatting highlights what needs attention, and the same template gets reused month after month.

Sales and performance tracking. Sales teams use Excel to monitor pipeline, commissions, and quota attainment. A regional manager might pull a report from a CRM, drop it into Excel, and use it to break down performance by rep, product line, or region.

Inventory and operations. Small and mid-sized businesses often manage stock levels, reorder points, and supplier data in Excel, especially before they've invested in dedicated inventory software. It's common to see formulas flagging low-stock items automatically.

Data cleaning before deeper analysis. Even in companies that eventually move data into Python or a database, Excel is frequently the first stop. Analysts use it to scan for obvious errors, missing values, and formatting issues before anything gets pushed downstream.

Ad hoc analysis and one-off questions. Not every question needs a full pipeline. When a manager asks "how did this product perform last quarter compared to the one before it," Excel is often the fastest way to get an answer, since the data's usually already sitting in a spreadsheet somewhere.

Formulas and Features That Do the Heavy Lifting

VLOOKUP / XLOOKUP. These are the classic tools for pulling matching data from another table, like grabbing a customer's region based on their ID. XLOOKUP is the newer, more flexible version, handling both directions of lookup and dealing with errors more gracefully than VLOOKUP ever did.

Pivot Tables. Arguably Excel's most powerful feature for analysis. Pivot tables let you summarize thousands of rows into a digestible table in seconds, grouping data by category, calculating totals or averages, and reshaping it without touching a single formula. A sales dataset with 10,000 transactions can become a clean summary of revenue by month and region in just a few clicks.

IF statements and nested logic. Conditional formulas like IF, IFS, and SUMIF/SUMIFS let analysts apply business logic directly into the data. For example, flagging orders as "Late" or "On Time" based on a shipping date, or summing revenue only for a specific product category.

COUNTIF / COUNTIFS. These handle quick counting tasks, like figuring out how many transactions fall into a certain category or how many days a metric stayed above a threshold, without needing a full pivot table.

Conditional Formatting. This turns raw numbers into visual signals, coloring cells red for underperformance or green for hitting a target. It's a small feature, but it dramatically speeds up how quickly someone can scan a report and spot what matters.

Data Validation. Used to control what gets entered into a spreadsheet in the first place, like restricting a column to a dropdown list of approved categories. This matters more than it sounds, since messy input at the source is one of the biggest causes of bad analysis down the line.

Charts and sparklines. Built-in charting tools let analysts turn a table of numbers into a trend line or bar chart without leaving the spreadsheet, which is often enough for a quick internal report or presentation.

How It All Comes Together

A typical real-world Excel workflow might look like this: pull raw data from an internal system, clean it up using IF and data validation to catch inconsistencies, use XLOOKUP to merge in reference data from another sheet, build a pivot table to summarize the numbers by category, apply conditional formatting to highlight outliers, and finish with a chart summarizing the trend for a report or meeting. None of these steps requires advanced technical skill on their own, but combined, they cover a huge share of what "data analysis" actually means in most workplaces.

The Takeaway

Excel doesn't get the same spotlight as newer data tools, but it's still where a massive amount of real-world analysis actually happens. It's not about being the most powerful tool available, it's about being fast, familiar, and flexible enough to handle the everyday questions businesses need answered. Learning it well, formulas, pivot tables, and all, isn't just a stepping stone to "real" data analysis. For a lot of roles, it is the real analysis.

Understanding Data Modelling in Power BI: Joins, Relationships, and Schemas Explained

Anthony Kibet — Mon, 30 Mar 2026 09:19:34 +0000

Data modeling is like building a well-organized library 📚. It helps us connect different pieces of information in a way that makes analysis easy and meaningful. In Power BI, data modeling is the process of defining how tables relate to each other, making sure data flows smoothly for reporting and insights. It involves creating relationships, understanding joins, and designing schemas — all to turn raw data into useful stories.

What is Data Modeling?

Imagine collecting data from different sources: sales data, customer info, products, and more. Data modeling arranges these data pieces in a logical way. Instead of having all data jumbled together, it structures it so you can analyze relationships: who bought what, when, and why? In Power BI, this is achieved through establishing relationships between tables, which allows you to filter, aggregate, and drill down into your data efficiently.

SQL Joins: (Data Combination)

SQL joins are ways to combine data from two or more tables based on related columns. Let's explore the common joins with simple examples:

1. INNER JOIN

What it does: Only shows rows with matching values in both tables.
Example: Find customers who made purchases. Only customers with sales records appear. -

2. LEFT JOIN (or LEFT OUTER JOIN)

What it does: Shows all rows from the left table, plus matches from the right table. If there's no match, you still see the left table row, but with blank info on the right.
Example: List all customers, even those who didn't buy anything (show blank for sales).

3. RIGHT JOIN (or RIGHT OUTER JOIN)

What it does: Opposite of LEFT JOIN; shows all rows from the right table plus matched rows from the left.

4. FULL OUTER JOIN

What it does: Combines everything from both tables; shows all matches and non-matches from both sides.

5. LEFT ANTI JOIN

What it does: Shows rows from the left table that do not have a match in the right.
Example: Customers who haven't made any purchase.

6. RIGHT ANTI JOIN

What it does: Rows from the right table with no match in the left.
Example: Sales records with no customer info.

Power BI Relationships: Building Connections 🌐

Unlike SQL joins, Power BI relationships are persistent links between tables that don't change unless you edit them. Here’s what you need to know:

Cardinality: How many related records exist:
- 1:M (One-to-Many): One record in the first table relates to many in the second. (e.g., one customer → many orders)
- M:M (Many-to-Many): Multiple records related to multiple. Requires bridging tables.
- 1:1 (One-to-One): One record relates to only one record.
Active vs Inactive Relationships: Active relationships are used by default when you analyze data, while inactive ones are stored but not automatically used. You can activate an inactive link when needed.
Cross-Filter Direction: How filters flow:
- Single direction: filters go one way.
- Both directions: filters flow both ways, useful for complex models.

Fact and Dimension Tables: The Building Blocks

Fact Tables: Store measurable data, like sales amount, quantity sold. Usually large.
Dimension Tables: Store descriptive info, like customer names, product categories. Usually smaller.

Schemas:

Star Schema: Fact table connected directly to dimension tables. Used for simplicity and fast querying.
Snowflake Schema: Dimension tables normalized into sub-tables, reducing data redundancy.
Flat Table (DLat): All data in one big table, but less efficient and harder to maintain.

Role-Playing Dimensions: Multiple Uses of a Single Dimension

Some dimensions, like Date, can be used to filter sales date, ship date, or invoice date. In Power BI, you relate the same Date table to multiple date fields to reuse.