Properties: Date format not following system settings on Linux (LANG vs LC_TIME)

Bug reports
, ,
1

Iʼm here on Linux (Kubuntu derivate “Tuxedo OS”) and set the OS date explicitely to German style and it does not adjust in view mode. The format in source mode is 2023-10-29:

Screenshot_20231029_130109
Screenshot_20231029_130109891×978 56.1 KB

Operating System: TUXEDO OS 2
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.0-10006-tuxedo (64-bit)
Graphics Platform: X11

I already restarted the OS multiple times. I would expect Obsidian to take either the system format or a custom style as suggested in Properties: let the user customize the way Dates/Times are displayed (independently from OS) - #52 by barabasz

Thanks!

2 Likes
2

With Linux it looks like this. So, is it a Chromium bug? My language is English whereas my date format is German. Perhaps Chromium uses the standard date format for the selected language instead of the date format independent of the standard format of the selected language?

Screenshot_20231101_182424
Screenshot_20231101_1824241778×727 109 KB

2 Likes
3

For Linux the problem is figuring out where chrome is reading the locale information. You are setting something for kde, but is it for kde or is it system wise?

4

Is there a way to find that out or wouldn’t that help with fixing this issue?

5

Linux: Obsidian seems to ignore LC_TIME variable. Instead, it follows LANG variable.

~$ export | grep UTF
declare -x LANG="en_US.UTF-8"
...
declare -x LC_TIME="cs_CZ.UTF-8"

Note example:

---
created: 2017-04-25T18:52:00
updated: 2024-07-12T15:53
---

Obsidian displays the datetime as “04 25 2017, 06 52 PM”, which is the US style.

Once I changed LANG=“en_GB.UTF-8”, the date is displayed European style: 25 04 2017, 18 52".

P.S. There does not seem to be a standardised approach to the order of importance of LANG, LANGUAGE, LC_ALL, LC_TIME. E.g. the summary here: linux - LANG and LANGUAGE environment variable in Debian based systems - Super User

2 Likes
6

Thanks for this information. I can confirm it. Since LC_TIME is meant as an override for LANG and does not have an effect on the way Obsidian displays the time/date format, I would consider this behavior a bug.

7

In the meantime, I am on Kernel 6.11 (based on Ubuntu 24.04.2) with KDE Plasma 6.3.5 (on Wayland) and the behavior remains the same.

8

+1 for following LC_TIME in Linux.
Just checked that this behaviour (only honoring LANG) happens in the latest 1.9.14 version of Obsidian as well.

9

t’s a live-view issue of the property:

If your switch to YAML/source-view the date should be displayed correct, only in the live-view it’s incorrect:

Live-View Property:

2025-12-13_15-05_obsidian_property_view
2025-12-13_15-05_obsidian_property_view881×370 18.1 KB

2025-12-13_15-05_obsidian_property_view2
2025-12-13_15-05_obsidian_property_view2935×249 14.6 KB

YAML/SOURCE VIEW:

2025-12-13_15-05_obsidian_property_view_yaml
2025-12-13_15-05_obsidian_property_view_yaml799×315 15.4 KB

10

Steps to reproduce

Prerequisites: A Linux machine with all instances of Obsidian closed (!).

1. Pick two locales with different date formats.
In my case:

  • en_US.UTF-8 ( mm/dd/yyyy )
  • es_ES.UTF-8 ( dd/mm/aaaa )

2. Launch Obsidian, assigning one of the locales to the LANG system variable, and the other one to LC_TIME:

LANG=en_US.UTF-8 LC_TIME=es_ES.UTF-8 obsidian

3. Open (or create) a note with a Property of type “Date” or “Date & time”. Notice, that the date format follows the locale set in LANG, not the one in LC_TIME:

image
image402×111 2.19 KB

4. Close all instances of Obsidian and run the same test again, this time with the locales swapped, to confirm that it indeed is the LANG variable that is being followed.

LANG=es_ES.UTF-8 LC_TIME=en_US.UTF-8 obsidian

Did you follow the troubleshooting guide? Y

Expected result

The date format should follow the LC_TIME locale (possibly with a fallback to LANG)

Actual result

The date format follow the LANG locale.

Environment

SYSTEM INFO:
Obsidian version: v1.9.14
Installer version: v1.8.10
Operating system: #1-NixOS SMP PREEMPT_DYNAMIC Fri Jun 27 10:11:46 UTC 2025 6.12.35
Login status: logged in
Language: en
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

11

Here adding an additional screenshot for step 4. of the Steps to reproduce :

image
image344×105 2.05 KB

12

This seems in line with how the date property format is set on other OSes: https://help.obsidian.md/properties#Date. There is a feature request for more display options:

13

It doesn’t seem to me to be inline with other OSes per the help page link you gave.
There it mentions

The date picker follows your operating system’s default date and time format.

But that it doesn’t do on Linux. That’s exactly what the bug report is about.

LANG is the fallback to use for anything, date & time, currency, language, if the more specific setting ( e.g. LC_MONETARY for currency ) isn’t present.

LC_TIME is the specific locale for date & time format.

As it stand right now, Obsidian doesn’t follow the OS setting for date & time but always falls back to the OS’ general locale.

I don’t know, if Obsidian reads the variables directly or indirectly, through some other utility, but in any case it comes up with the wrong value.

14

I was going by the Help page’s callouts for Windows and Mac, which specify settings in “Language and Region”. I didn’t know LC_TIME was locale-related.

There may be more details about what’s going on in the discussion of the feature request I linked, if you feel like digging into that.

15

Fair enough regarding the Windows callout. The MacOS callout, however, does show specifically setting the “Date format”.

This page describesLANG and LC_TIME relate to each other on POSIX systems.

I can see the in the discussion you linked, that @am4c130d, @iomys, and @argentum have also mentioned this issue. However, since the feature request, at least per it’s title, is asking for the option to change the date & time format within Obsidian, independently of the OS, I believe this topic should be continued here.

I did some digging, and it seems that the cause of this issue traces back through Electron and NodeJS into V8.

  • Here someone noticed, that NodeJS uses the LANG locale instead of the LC_TIME as the default locale for date formatting with toLocaleString().
  • On MDN it is mentioned that the toLocaleString() function is often implemented as depending on the Intl namespace, which in my own testing also uses the wrong locale.
  • In this StackExchange question, the OP noticed this issue in their browser. The reply mentions there are bug reports for this behavior for both, Firefox and Chrome. Indeed, the Firefox bug report is still open at the time of writing this.

I can see that the issue arguably is caused upstream of Obsidian, and also that it only affects few users, namely those who use Linux and have at some point changed their OS’s default date & time format.
However, it stands that Obsidian’s intended behavior according to it’s help pages, i.e. to follow the OS’s default date & time format, differs from it’s actual behavior. Thus, this constitutes a Bug.

Without knowing the code in detail, it seems to me, it could be fixed by reading the process.env.LC_TIME environment variable and, if it is set, providing it to the relevant invocations of toLocaleString(), or whatever function is used to turn dates to strings.
It may seem a bit presumptions of me to give suggestions on how to implement a fix, I hope you’ll forgive me that transgression. My only aim is to illustrate that a fix does seem possible.

To be honest, I am a bit surprised by the responses so far. Or perhaps I am mistaken, and this is not the place to report bugs? That said, it remains entirely your choice whether to address the issue or leave it be. As such, I don’t think I will press this any further and may not invest more time into this.

Kind Regards

3 Likes
16

Yes, this is the right place to file bugs (tho it’s possible the devs may choose to fold this report into the feature request or something). That’s great info you dug up!

1 Like
17

Thank you!

I’ll leave here two relevant quotes from the page I linked above, for any devs that might look into this, for whatever purpose:

LC_TIME
This variable shall determine the locale category for date and time formatting information. […]

LANG
This variable shall determine the locale category for native language, local customs, and coded character set in the absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables.

So LANG should only be used as a fallback for LC_TIME.

I shall try next time to include this information in the “Additional Information” section of the bug report. I didn’t realize at the time that Obsidian probably doesn’t read any of these environment variables directly.

Best Regards

2 Likes
18

@SynDev Please tell us that you found a workaround!?!

I have been going around in circles with trying to get the date property in the bases table view to be in the only true correct format (end sarcasm) of YYYY-MM-DD, but I keep getting stuck with dd/mm/yyyy.

I too am on Linux, and no locale for LC_TIME seems to resolve the issue despite every search result suggesting: LC_TIME = "en_DK.UTF-8"

Somehow the journal seems to be fine with this format and I can’t find anywhere else that this is an issue, but the Date property in bases is so prominent and garish that I am questioning this whole program (end hyperbole).

20

I merged these two duplicate threads.

Regarding using LANG vs LC_TIME (which would be more appropriate). It’s something we get from Chromium/Electron.

It’s also possible to force the app to use a specific Language using a command line switch --lang=en or --lang=fr, etc.

I don’t think this problem will be address until we implement our own way of