Bases - pass argument(s) to functions/filters?

Help
,
1

I am playing around with Bases and looking to see if it can replace dataview for at least some of my needs.

The simplest DV query that I have is a “all notes created/edited $today” which is implemented using the user scripts:

// if input.filter_date is not defined, default to today
if (!input.filter_date) {
  input.filter_date = new Date().toISOString().split('T')[0];
}

dv.execute(`
  TABLE dateformat(file.cday, "yyyy-MM-dd") as "Created${input.exclude_self ? '(excluding self)' : ' (including self)'}"
  WHERE file.cday.year = date(${input.filter_date}).year
      AND file.cday.month = date(${input.filter_date}).month
      AND file.cday.day = date(${input.filter_date}).day
      ${input.exclude_self ? 'AND file.path != this.file.path' : ''}
  SORT file.cday desc
`);

And then in my daily note template, I have this:


# Heading 

- And other markdown content here

## today's activity

```dataviewjs
await dv.view("_meta/dv/dv_daily_activity", {filter_date: "<%today%>", exclude_self: false});
```

Which would render a very basic table showing any file that was created today.

What I’m trying to do

I would like to have a daily-activity.base file that can be embedded in each daily note so the base renders notes only from $thatDay.

I can’t use now() because that will always be $today and I can’t figure out how to pass inputs to filters / functions or even reference $self (the location /note where the base is being displayed).

If $self was an option then I could - theoretically - write a basic:

    filters:
      and:
        - file.ctime > $self.ctime #insert code(?) here to cut the H:M:S out of ctime, just to scope it to the day.

Things I have tried

  • Searching this forum / reddit / HN discussion threads
  • Play around with the base builder gui/the raw .base file on disk
2

In Bases, it’s called “this”: Bases syntax - Obsidian Help

For example, this.file.name references the current note’s name. And this.cday would be your cday property in the current note.

1 Like
3

wow, I feel dumb for having missed that the first time.

There’s still something very off, though.

Here’s the content of my test.base file:

views:
  - type: table
    name: Today's Activity (ctime)
    filters:
      and:
        - file.ctime.year == this.file.ctime.year
        - file.ctime.month == this.file.ctime.month
        - file.ctime.day == this.file.ctime.day
    order:
      - file.name
      - file.ctime
      - created
      - edited_seconds
      - modified
    sort:
      - property: modified
        direction: ASC
    columnSize:
      file.ctime: 204
  - type: table
    name: Today's Activity (front_matter)
    filters:
      and:
        # With just the year, I get 8 results which is _very_ wrong: there should be ~200 notes, one for each day of the year so far...
        - date(created).year == this.file.ctime.year
        # With just the year/month selection, I get just two results which seems wrong given that I have 20 notes for the 2025-08 timespan so far...
        # - date(created).month == this.file.ctime.month

        # Including this and I get no results
        # - date(created).day == this.file.ctime.day

    order:
      - file.name
      - created
      - edited_seconds
      - modified
    sort:
      - property: modified
        direction: ASC
    columnSize:
      file.ctime: 204

The first view, using ctime is doing what I expect but has it’s own issues due to the way Syncthing works. The ctime property is unique to the host and not immutable. If I create a file on my desktop today but my laptop is sleeping / offline until tomorrow, that note won’t be present on my laptop until tomorrow. The ctime for that note will be “wrong” but only on my laptop.

To counter this, I have a created field in my front-matter which is updated by a plugin when the note is first created. Here is what the front matter from today’s note looks like:

---
aliases: []
tags:
  - kind/dailyNote
created: 2025-08-19T07:57:49.000Z
template_info:
  template: daily-note
  version: 1.9
modified: 2025-08-19T15:57:22.943-07:00
edited_seconds: 1
---

Is there a debugger or other way to inspect what’s happening inside the filter? There’s clearly something wrong with the date(created) parse but I don’t have a way to “show/inspect” what was parsed or if there was an error. I am very familiar with chrome dev tools but there’s nothing emitted in the logs when the base file is loaded or when I switch between the views.

4

Unfortunately, it looks like a formatting issue.

Bases needs the datetime in your YAML to be formatted as YYYY-MM-DD HH:mm:ss (reference in the docs). Even though it’s not listed on that page in the docs, YYYY-MM-DDTHH:mm:ss also works (with the “T”).

Other components like time zones and daylight saving indicators seem to be a no-go, even popular standards like what you’re using.

To confirm, you can make a new column with this date-checker formula:

created.date()

… and see it return an error for the note in your example. That would by why some notes don’t get through your year-comparison filter.

Since Bases sees it a string, you could use a formula to slice off the extras and wrap the remaining string in date(). For example, either of these would get you just the year:

purchase_date.slice(0,4)

date(purchase_date.slice(0,19)).year

Or you could update all of your frontmatter entries. :grimacing:?

5

Ouch. No timezone support means this is useless for anybody that:

a) likes to record $when something happens
b) travels or otherwise likes to include $where with $when.

There are a few of us, maybe even dozens of us that fit that intersection, dozens!

You’re right, though. When I have this in my base:

    filters:
      and:
        - date(created).year == this.file.ctime.year

The only items that render are items that have just YYYY-MM-DD format and not full ISO8601.

I’m not sure I follow? Here is my base:

formulas:
  date_check: created.date()
views:
  - type: table
    name: Today's Activity (front_matter)
    filters:
      and:
        - date(created).year == this.file.ctime.year
    order:
      - file.name
      - date_check
    sort:
      - property: modified
        direction: ASC
    columnSize:
      file.name: 380
      note.date_check: 221

I start with a new/empty note (no front matter, no nothing).
I open CDT and clear the console.
I type out the link to the base file.
I click the link and the base file opens in a new tab
I only see two columns: file name and date_check.
I see no errors in the console or anything else to indicate that there were hundreds of files that somehow didn’t parse correctly.

Just as a sanity check, I removed this:

    filters:
      and:
        - date(created).year == this.file.ctime.year

and saved. The view reloaded and the file name column had 8.5K results which is ~ the total number of files in my vault.

In theory there was no filter/selection so the date_check should have been computed for every file, right? Nothing in the console to suggest an error/failure.

That’s an idea / could work. I’ll hold off on implementing though. DataView works and until Bases supports timezones, being able to directly access the underlying moment.js functions is a pre-req.

I’ll skim the release notes going forward to see if Bases exposes the underlying moment.js or otherwise gets TZ aware datetime functionality.

6

Yep, I change time zones too. When it comes up, I’ll probably just slice them off within Bases so I can keep the values in my notes.

… while hoping the feature gets built in.

  1. Remove that filter (as you later did). Otherwise you’re filtering out the notes you want to check.
  2. Call your formula as formula.date_check. Otherwise you’re displaying a presumably nonexistent front matter property called “date_check”, which has no values.

Essentially:

```base
formulas:
  date_check: created.date()
views:
  - type: table
    name: date checker
    filters:
      and:
        - created
    order:
      - file.name
      - created
      - formula.date_check

```

date checker
date checker1116×845 35.6 KB

1 Like
7

Ah ha. That’s what I was missing :D. Thank you.

I can reproduce, now. I’ll have a play around with how much of the full JS api is available from filter: context. It won’t be pretty, but I might be able to put the string(s) (looking over vault, there are a few different formats) to Date parse in there.

1 Like
8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.