obsidian-projects
obsidian-projects copied to clipboard
Datetime field type
What would you like to be added?
Since Obsidian Projects already supports date field types, I'd like to suggest the addition of a datetime field type, which keeps compatibility with the former.
More specifically, during the type inference of a field, the common denominator type for a field with either dates (YYYY-MM-DD
) or datetime values (YYYY-MM-DDTHH:MM:SS
or YYYY-MM-DD HH:MM:SS
) should be 'datetime', as opposed to 'text'.
Since Obsidian Projects allows setting date values from certain views (e.g. Table View) using a native HTML date
input type, that could be changed to datetime-local
to allow setting time values alongside a date:

Obsidian Dataview (and probably also the future Datacore) supports datetime values, meaning that using dataview queries as data sources would still play well with the new type.
Why is this needed?
Having more granular timestamps for projects would help with organizing multiple tasks/projects during a single day. For example, the "Demo project" bundled with the plugin features entries with a "due" field, which could be even better if showcased using datetime values.
This is one thing I'd really like to see in the plugin, as I'm considering switching some workflows to Obsidian from another app, where this kind of feature proved very helpful.
Thanks for your work on Obsidian Projects!
Thanks for the suggestion! 🙏 I think it makes sense to support datetimes.
I'm not yet sure how to represent them though. For example:
- Extend current Date field type with support for time.
- Introduce a Datetime field type with support for both date and time.
- Introduce a Time field type to complement the current Date field type.
If we create separate Date and Datetime field types (2), it's going to make it harder to configure the Calendar if you want to mix date and datetime events.
Similarly, I think it might be annoying to have to configure a separate Time field (3).
I'm leaning towards (1), but then we'd need to figure out what it means when records mix date and datetime formats. We could add a field config option whether to include time or not.
- If enabled, 2023-01-01 will be interpreted as 2023-01-01 00:00.
- If disabled, 2023-01-01 14:23 will strip the time and be interpreted as 2023-01-01.
Nice ideas, hope for that feature, too! 👍
I would like support for ISO 8601 longform dates in the format YYYY-MM-DDTHH:mm:ssZ
. This format is supported by Obsidian Properties and other plugins like Dataview. And it eliminates problems with time zones because the time zone is baked in.
Practically speaking most systems (like databases such as Postgres) support date
and datetime
types independently. But few support an independent time type. I could see "time" being useful for like daily things like cron jobs and pill reminders, but I would not worry about that for now. Thus I would lean towards option 3 - not least of all because it maintains compatibility with all other Obsidian core and community plugins.
Google Calendar separates "all day" events from set time events. I think for a first pass it would be fine for the calendar view to not really allow mixing them.
And yes, every system and programming language and library I've used where the time is optional when parsing a datetime field will return midnight for that given date.
Google Calendar separates "all day" events from set time events. I think for a first pass it would be fine for the calendar view to not really allow mixing them.
Regarding this, as Calendar view currently only accepts one field as its date feed, I think it won't cause problem if we support datetime field and utilize it to locate records. It would be a good start to make Calendar view recognize datetime fields.
Any updates on this? Obsidian's date & time property type won't show time in table view.
@Hexara7777 will be worked on next. Thanks for reminding me about datetime support of the Table view!
@Acylation Yay! Nice to know that, you're welcome.
Instead of focusing on which of the date, time, and datetime types is best to use, I'd suggest considering how the upcoming Temporal API distinguishes between the different kinds of time.
If I understood the proposal correctly, there are generally three types of time:
- Instants – The moment something happens, like a timestamp.
- Zoned date times – This is what I'd use to set up meetings across time zones.
- Plain date times – Alice eats breakfast every morning at 7:00 AM, or Bob gets paid every 15th of the month.
This kind of distinction isn't available in Notion as far as I'm aware, and it's something I found myself needing on different occasions. Here are some examples off the top of my head where I could have used this:
Thing | Type of time |
---|---|
Flight times | Zoned date times |
Meetings | Zoned date times |
Habit trackers | Plain date times |
Project completion dates | Instants (or possibly zoned date times) |
Friends' birthdays | Plain date times |
This article from the proposal goes into more detail about the potential ambiguity that the Temporal API aims to solve.
It would be exciting to have this kind of granularity in Obsidian, and I hope that it's something the maintainers will consider!
Recommend support 2024-01-01T13:34:36+08:00
This time format is the ISO 8601
date time format. This format represents date time with readability and international uniformity.
Hi, just curious if there have been any new updates or plans regarding this issue ?
Now the "Date&Time" Property would be treated as plain text.
Could it be treated as "Date" (just throw the time) at least? ( Though it would be the best to add support for Date&Time <3 )
+1 this feature
This issue is labeled as being actively worked on, let's hope it gets adressed soon.
Cheers @Acylation
Hi @marcusolsson, could you take some time reviewing these implementations? I'm a bit hesitant between them as Obsidian now seems treating Datetime as a unique field type (so does the list type but this is for another day), while I agree that proposal (1) is more flexible and can eliminate the detection of mixed-type field.
Edit: With respect to the above discussions, proposal 1 will be put into use.