Bases: Inconsistency in how non-existing date strings are handled by the date() global function between MacOS & iOS/iPadOS

Steps to reproduce

  1. Create or open a “mobile sandbox vault” which can be synced between Obsidian desktop and Obsidian mobile (more specifically iOS or iPadOS)

  2. In said vault, create a note with the following content:

    • Note: the key dateString needs to be set as a text key (as the date string needs to represent a non-existing date corresponding to: “the end of the month + 1 day”, at least)
---
dateString: 2025-11-31
---

~~~base
formulas:
  date1: date(dateString)
  date2: date("2025-02-29")
views:
  - type: table
    name: Table
    filters:
      and:
        - file.hasProperty("dateString")
    order:
      - file.name
      - formula.date1
      - formula.date2
    columnSize:
      formula.date1: 125

~~~

  1. Open the note, once synced across devices, in Obsidian on desktop and on mobile (iPhone and/or iPad as this seems to be a mobile Apple “thing”)

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

Yes :blush:

Expected result

That the global date() base function would handle the non-existing date string on iOS/iPadOS like it does on desktop, I guess :blush:

As bases can appear as “broken” on iPhone/iPad while working perfectly fine on desktop (leading to unnecessary troubleshooting/confusion)

Maybe just adding an error message in this (edge ?) case on iOS/iPadOS could possibly make things clearer from a user point of view :blush:

Actual result

So, I know that both date strings in the sample ("2025-11-31" and "2025-02-29") don’t exist as dates but desktop seems to handle them by returning, as dates, what would be the next day:

  • The formula date(dateString) → outputs: 2025-12-01 on desktop but nothing on iPad/iPhone
  • The formula date("2025-02-29") → outputs: 2025-03-01 on desktop but nothing on iPad/iPhone

… meaning that on desktop, dates and date strings manipulations appears to be working fine but that’s not the case on iPad/iPhone as formulas “breaks” by not returning anything (no errors in the cells, they’re just blank)

Here’s a screenshot of the base shared above on desktop:

Here’s a screenshot of the same exact base on iPad:

Same but on iPhone:

Environment

Desktop:

SYSTEM INFO:
	Obsidian version: v1.10.3
	Installer version: v1.10.3
	Operating system: Darwin Kernel Version 24.6.0: Wed Oct 15 21:12:08 PDT 2025; root:xnu-11417.140.69.703.14~1/RELEASE_ARM64_T6020 24.6.0
	Login status: logged in
	Language: en
	Catalyst license: supporter
	Insider build toggle: on
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

iPad:

SYSTEM INFO:
	Operating system: ios 18.7.2 (Apple iPad8,9)
	Obsidian version: 1.10.3 (251)
	API version: v1.10.3
	Login status: logged in
	Language: en
	Catalyst license: supporter
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

iPhone:

SYSTEM INFO:
	Operating system: ios 18.7.2 (Apple iPhone17,1)
	Obsidian version: 1.10.3 (251)
	API version: v1.10.3
	Login status: logged in
	Language: en
	Catalyst license: supporter
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none


Additional information

This was spotted by someone looking for help in the dedicated #obsidian-bases channel trying to build a “birthday tracker” using a base which didn’t seem to work for someone born on a leap day: here

Dawni/Purple Penguin ended up suggesting to try with this birthday base shared on Discord: here instead but what appeared to work on desktop and android, didn’t work neither on iPhone nor iPad, as reported starting out there :blush:

Hi.

How do you get Properties to show the date: 2025-11-31? When I use your sample file, it is rejected:

I forgot to mention it :sweat_smile: … and I’ve just edited the post :blush:
Thank you for the reminder :grin: !

As the date string needs to represent a non-existing date, the key dateString needs to be set as a text type of key :innocent:

Although Properties doesn’t handle the non-existing date if dateString is set as a date type of key, the value is still stored in Source which then appears to be handled by date() in the base in the same way as it does when the key is set to text (at least on desktop… that still “doesn’t work” on iPad/iPhone )

… which also looks a bit inconsistent when it comes to desktop …

… vs. iPad (and possibly iPhone) :sweat_smile: :

1 Like

Thank you.

:see_no_evil_monkey: How did I not notice the different icon? :tired_face:

Interesting that it only works if the day is not greater that 31. Change it to 32 or 33, and …

1 Like

Yes, this is probably more of a edge case than anything else :sweat_smile:
Or, as Obsidian and base are evolving quite fast, maybe there’s still a missing piece which still need to be implemented for date() to handle this consistently across MacOS/iPhone/iPad :woman_shrugging:

1 Like

Thanks for writing the report, Pch.

I couldn’t find anything about this being a known moment.js thing on iPad. It made me wonder whether some tree shaking Obsidian did left out a lil sumthin that’s required. And that’s where my capabilities to look into this ended.


lostinbase,

Interesting that it only works if the day is not greater that 31.

The dates mechanism is responsible for that and pretty standard practice[1]. Days of the month in excess of real days and up to 31 bubble up to the next month. I imagine there’s not good enough reason to extend it beyond 31 days either infinitely or arbitrarily.


  1. I just learned this around the time Bases was released because people were asking for birthday countdowns ↩︎

2 Likes

My pleasure :smile: !
I had a little bit of time to spare and the whole thing got me curious :laughing:
I still couldn’t understand why this inconsistency exists and I also thought it could be worth reporting it (even just in case :woman_shrugging: )

And thank you for bringing some light on the date mechanism at work here: TIL :grin: :raising_hands: !

1 Like

Yep, figured about the date mechanism hitting 31, but then wondered if weird things might still happen if it was being listed as a text field rather than a date. As ever, I know nothing, but the thread is an interesting read.