Bases: date comparison against file.ctime mtime are incorrect

[esamecar]

Steps to reproduce

1. Create an empty base that shows all files
2. add filter for All views, where “file.ctime” is “on” and pick a date, e.g. todays date
3. done

Expected result

All files created today should be shown.

Actual result

Empty list is shown.

BUT after changing to “on or after” it does work. (In the screenshot I chose today’s date and because there are no files created in the future all files shown have been created today.)

Environment

SYSTEM INFO:
Obsidian version: v1.9.4
Installer version: v1.8.9
Operating system: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:33 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8122 24.5.0
Login status: logged in
Language: de
Catalyst license: insider
Insider build toggle: on
Live preview: on
Base theme: light
Community theme: none
Snippets enabled: 1
Restricted mode: off

---

Additional information

[WhiteNoise]

Yes, the UI is wrong. ctime is datetime, so you should be asked to provide a time as well.

[ariehen]

I think this a duplicate of the following topic; I linked to a post with some workarounds for now:

https://forum.obsidian.md/t/bases-dont-filter-by-file-ctime-and-file-mtime-dates-using-the-simple-filter-builder/101668/6?u=ariehen

[esamecar]

@WhiteNoise

Yes, the UI is wrong. ctime is datetime, so you should be asked to provide a time as well.

Thanks! UI wise, does it makes sense to compare a datetime with “on” to another datetime? How big are the chances that they will be the same?

A user, that wants to use the UI and not the more complex syntax, I think, would always want the ability to compare e.g. the file creation date with another date … Any chance for the addition of file.cday maybe?

[esamecar]

BTW maybe this could be clarified in the help as well? Right now it is called “.ctime”, has type “Date”, but the Descriptions states “time”. The type might be “DateTime” and the description “Created date with time”? (As a non-programmer this is quite confusing to me.)

[tnaseem]

Steps to reproduce

1. Create a new bases table.
2. Add a filter for the view "file.ctime > “2008-01-01”

Did you follow the troubleshooting guide? [Y/N]

Yes

Expected result

The table should list all the notes with the created date after 2008-01-01

Actual result

No results are shown the table

Environment

SYSTEM INFO:
Obsidian version: v1.9.2
Installer version: v1.5.12
Operating system: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6000 24.5.0
Login status: logged in
Language: en
Catalyst license: insider
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

---

Additional information

I have tried file.ctime and file.mtime and both show no results, despite the created and modified times for the files being after 01-01-2008.

The only filter that works for these properties are “is empty” or “is not empty”.

I found a similar post which suggested using the dateOnOrAfter() function, but Obsidian gives me the error “Failed to evaluate a filter: Cannot find function dataOnOrAfter”.

The base file:

filters:
  and:
    - file.folder == "Journal"
views:
  - type: table
    name: All
    filters:
      and:
        - file.ctime >= "2008-01-01"
    order:
      - file.name
      - tags
      - created
    columnSize:
      file.name: 422
      note.tags: 155
      note.created: 123
    sort:
      - column: note.created
        direction: DESC

Oh, I also tried created >= "2008-01-01", with the same results.

Examples

With the date filter, I get no results:

Remove the date filter, and the notes show up:

[tnaseem]

Some further investigation…

Creating a filter date(file.ctime).year == 2008 seems to work.

[ariehen]

file.ctime >= date("2008-01-01") should also be fine.

---

There should be a way to do this using the simple filter builder though.

[tnaseem]

Ah, yes. Thanks. That indeed works too.

I should have clarified actually - I was using the simple filter initially, but started to fiddle in the advanced mode afterwards. Either way, you’re right; it should work regardless.

[ariehen]

I played around a bit more trying to get files created on, on/after, etc., a certain date to work using only the simple filter builder, but couldn’t get it.

I’ll add that to the topic title for clarity.

[dawni]

I thought this would be a good place to put the workarounds for each type of date comparison, as they also describe the bug for each type.

The issue seems to be that the simple filter builder doesn’t determine whether .date() or date(...) is needed thus doesn’t write them in.

So to overcome “failed to evaluate” warnings and get expected results when using the simple filter to…

… compare a datetime to a date string:

simple filter	workaround
on, not on	append .date() to the date
before, after, on or before, on or after	wrap the date string in date()

… compare a date to a date string:

simple filter	workaround
on, not on	works as expected
before, after, on or before, on or after	wrap the date string in date()

Examples of the types:

• datetime
  • file.mtime
• date
  • file.mtime.date()
  • date(this.file.name) on a daily note named “2025-01-01”
  • a custom date property named dateBegun
• date string
  • “2025-01-01”
  • this.file.name on a daily note named “2025-01-01”

[Grabrp]

Steps to reproduce

1. Create a new note.
2. Give that note a new property “myProperty” of type date.
3. Set myProperty to the date value “2025-01-01”.
4. Create a new Base.
5. As a filter condition, select the filter attributes (a) myProperty (b) “on” and (c) “2025-01-01”. You are now seeing the note you just created. When editing the filter expression, it says [myProperty == “2025-01-01”]. All good.
6. Now change the filter condition from “on” to “on or after”. Keep the date value as it is.

Did you follow the troubleshooting guide? [Y/N]

[Y]es, I did test this in the sandbox vault. Same behaviour.

Expected result

Clearly you would now expect the same note to still be shown since the condition “on or after” is less strict than “on”.

Actual result

The note is not listed. All kinds of notes are listed where the property is empty.

I understand/learned that I can fix this by explicitly converting the date string to a date object, like date(“2025-01-01”). However this is highly confusing for two reasons:

1. This is not needed when using “on” as the filter condition.
2. I used the UI to create my filter so I would absolutely expect either (a) no date() wrapping to be needed or at least (b) for the UI to add it since the field I entered my filter condition value “2025-01-01” in is a date field, not a string field, so the UI knows I’m entering a date.

Environment

SYSTEM INFO:
Obsidian version: v1.9.2
Installer version: v1.8.10
Operating system: #1 SMP PREEMPT_DYNAMIC Thu, 22 May 2025 05:37:49 +0000 6.14.7-arch2-1
Login status: logged in
Language: de
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Base theme: dark
Community theme: Mado Miniflow v1.4.2
Snippets enabled: 2
Restricted mode: off
Plugins installed: 21
Plugins enabled: 18
1: Dataview v0.5.68
2: Minimal Theme Settings v8.1.1
3: Emoji Shortcodes v2.2.0
4: Advanced Tables v0.22.1
5: Map View v5.5.0
6: Paste URL into selection v1.7.0
7: Templater v2.11.1
8: Meta Bind v1.4.1
9: Auto Link Title v1.5.5
10: Homepage v4.2.2
11: Style Settings v1.0.9
12: Relative Line Numbers v3.0.0
13: Calendar v1.5.10
14: Periodic Notes v0.0.17
15: Vimium v1.0.0
16: Slides Extended v2.1.12
17: Media DB v0.8.0
18: QuickAdd v1.13.3

---

Additional information

In my humble opinion, but I appear to be wrong (since I appear to be the first to report this bug), this is quite severe since date comparisons are going to be used often, as is the UI for creating such filters. The behaviour seems so random (“on” works, “on or after” not at all) and drove me crazy.

[ariehen]

Seems related to this report:

https://forum.obsidian.md/t/bases-dont-filter-by-file-ctime-and-file-mtime-dates-using-the-simple-filter-builder/101668/6

[Grabrp]

Indeed. I did not check that bug report since from its title it seemed to be related to specific file properties when it is about date comparisons created via the filter builder. I will leave it to the moderators to decide which one to keep.

[WhiteNoise]

this will be fixed in v1.9.5. No ETAs.