Remove date format option

[Tyrrrz]

Flavor

No response

Export format

No response

Details

Date format option was introduced a long time ago, where its usage was limited to message timestamps. It was introduced as a crude way to enable users to format timestamps in the export the same way they appear in their Discord client (in their respective locale).

Since then, a few things happened:

• We added support for embeds, which can contain timestamps in the footer. These timestamps are not formatted the same as other dates in the client.
• We improved the layout of the HTML export to show message time on hover. This timestamp only includes the time component and is, as a result, not formatted the same way as other dates in the client.
• We introduced the JSON export format, which formats all timestamps according to the way they are written when you call JSON.stringify(...) in JavaScript (which is a common practice in JSON outputs).

Reconciling these nuances with the existence of the date format option has become a nuisance. My suggestion is to remove the date format option and do the following instead:

• Format message timestamps according to user's system locale
• Format other timestamps the same way they are presented in Discord
• Additionally show tooltips with the timestamps formatted in a deterministic format that includes the time zone identifier

[zabszk]

Tooltips are definitely better (and easier to use, no need to scroll to the preamble) than adding timezone to the preamble. Let's keep in mind that some people may want to use UTC timestamps (eg. #287). Currently it's possible by using the u date format, but it's suggested to remove it. So I think it's worth considering to use u format for the tooltips.

I'm not sure whether removing date format field completely is the best way. Maybe it would be better to just set the default value (on the first DCE launch) according to user's system locale? That way we don't remove the ability to customize the exports.

But overall I support this suggestion.

[Tokariew]

What about… exporting messages to plain text… It's need some kind of time formatting…
Format message timestamps according to user's system locale And this option is not necessary nice, if you use docker… in which i don't think is option to setup easly locale…

[zabszk]

What about… exporting messages to plain text… It's need some kind of time formatting… Format message timestamps according to user's system locale And this option is not necessary nice, if you use docker… in which i don't think is option to setup easly locale…

That's why I think that instead of removing the date format option we should set the its default value according to the user's system locale (instead of setting it to some static default format). In that way we still allow user to customize the time format while making the default format friendly (so a lot of users don't need to customize it).

User may want to customize the format for a couple of reasons:

1. Exports can be made by multiple users from different countries (eg. within an organization) and they want to have the same format in all exports.
2. Export may be done on someone else's PC with different locale settings (someone is exporting a chat from his friend's PC that has a different locale settings, VM/Docker with default settings, etc...).
3. Locale settings leak some information - informs from which country the exporter is. There are situations in which you want to hide this information by changing the format.
4. Someone may want to use a specific date format, different than the local one, eg. the u format.

That's why I suggest to keep the settings, but modify its default value according to user's locale instead of using a static format as a default one.

[Tyrrrz]

The main issue is that there is no one date format to configure, as timestamps are rendered differently in different places. It would make sense to make the locale configurable instead. But I think you can already do that in Docker without application level settings (googling around yields some results, but I haven't tried).

[Tokariew]

Running with -e LC_ALL="en_GB.UTF-8" seems to work. Running with such option result in following output of locale for me

root@cb2d53787251:/out# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=en_GB.UTF-8

probably only LC_TIME is enough to setup as env

[zabszk]

The main issue is that there is no one date format to configure, as timestamps are rendered differently in different places. It would make sense to make the locale configurable instead. But I think you can already do that in Docker without application level settings (googling around yields some results, but I haven't tried).

There are many situations (I listed some of them earlier) when you would want to use a different format than the one set in the OS settings. And we can't forget about some people wanting to export in UTC (eg. #287). I'm not sure if that can even be set in locale settings without changing the timezone (and that affects many other aspects of the OS and other applications).

I don't see any reason why timestamps should be rendered differently in different places. I would rather display all timestamps in the same format - the one set by the user (which by default should be set according to OS locale). That makes more sense than taking away extra configuration ability and then using OS locale everywhere. If we want to use the same format everywhere why not keep the ability to customize it?

[Tyrrrz]

I don't see any reason why timestamps should be rendered differently in different places

Discord renders them differently in different places, so to stay consistent we need to as well

[zabszk]

I don't see any reason why timestamps should be rendered differently in different places

Discord renders them differently in different places, so to stay consistent we need to as well

So what's the plan? Read users locale and adjust all formats according to the locale and make them look like on Discord? That would require having some sort of list of how date in each place looks for every possible locale. That's of course doable, but will require a lot of work. Or do we just use short/long date format from OS locale and ignore how it would look on discord?

In both cases I suggest keeping the custom date format textbox that would override the format everywhere, eg. to allow exporting in UTC.

[96-LB]

What's the plan for dates in embed footers (#648)? If the Discord API returns them as a date but the Discord client renders them incorrectly, how would you be able to format them the same way as Discord? Does every embed use the same format for their timestamps?

Regarding the use cases that @zabszk brought up, I think a setting to tweak timezone/locale would cover most of them. It's pretty reasonable, in my opinion, to want to deviate from your system's default settings, and many apps seem to provide that functionality. I do agree that a fully customizable date format like we have now has gotten a bit messy with the additional complexity that DiscordChatExporter has accrued, though.

[zabszk]

What's the plan for dates in embed footers (#648)? If the Discord API returns them as a date but the Discord client renders them incorrectly, how would you be able to format them the same way as Discord? Does every embed use the same format for their timestamps?

The question is whether we should format timestamps exactly the same way as Discord does (unless user overrides the format in the settings)?

I do agree that a fully customizable date format like we have now has gotten a bit messy with the additional complexity that DiscordChatExporter has accrued, though.

Do we want to have the ability to override every possible format/place separately or do we want just one config that overrides every date format?

[CanePlayz]

I have some things in regard to this topic:

1. How are the message timestamps that appear when you hover over a message (the ones at the left that only include time) currently being formatted? Does DCE just take the time component of the custom date format given by the user and format the timestamp accordingly?

2. It gets even more complicated if we want to replicate Discord's behavior perfectly. The timestamp shown when hovering over a message time doesn't match the normal timestamp on messages.

3. Discord has a preset for each language setting including

• the format for the timestamp next to the user's name
• the format for the short timestamp on the left of messages
• the format for the timestamp that appears when you hover over a timestamp

What if we allowed users not to completely customize the timestamp, but instead use one of Discord's presets (e. g. German, English-US)? We could have a table with all 3 formats for each language. That way, we wouldn't have to use a custom date format from the user for different areas and we would come even closer to Discord's behavior. However, I don't know if there would be any new problems with that.

4. If I saw it correctly, the timestamps at the bottom of embeds are formatted the exact same way as the timestamps right next to the user's name.

[Tyrrrz]

1. How are the message timestamps that appear when you hover over a message (the ones at the left that only include time) currently being formatted? Does DCE just take the time component of the custom date format given by the user and format the timestamp accordingly?

No, it ignores the provided format and uses a hard-codded one (which is just HH:mm, I believe).

2. It gets even more complicated if we want to replicate Discord's behavior perfectly. The timestamp shown when hovering over a message time doesn't match the normal timestamp on messages.

If we make the format non-configurable, then we can easily have different formats for different places, just like Discord does.

3. Discord has a preset for each language setting including

• the format for the timestamp next to the user's name
• the format for the short timestamp on the left of messages
• the format for the timestamp that appears when you hover over a timestamp

What if we allowed users not to completely customize the timestamp, but instead use one of Discord's presets (e. g. German, English-US)? We could have a table with all 3 formats for each language. That way, we wouldn't have to use a custom date format from the user for different areas and we would come even closer to Discord's behavior. However, I don't know if there would be any new problems with that.

From the perspective of code complexity, Discord's approach is simpler since we can just extract regional format settings from the built-in system cultures.

On Windows, it corresponds to this:

We can have the drop down just like Discord, or just use the current system culture. Obviously, I prefer the latter.

Allowing the user to configure each separate format adds complexity, isn't future-proof (what if another format appears?), and I doubt there will be many people who will actually want to do that.

4. If I saw it correctly, the timestamps at the bottom of embeds are formatted the exact same way as the timestamps right next to the user's name.

I think the embed timestamps have the same format regardless of user settings. I believe you pointed it out in the past: #648

[CanePlayz]

No, it ignores the provided format and uses a hard-codded one (which is just HH:mm, I believe).

Ok

If we make the format non-configurable, then we can easily have different formats for different places, just like Discord does.

Yeah

From the perspective of code complexity, Discord's approach is simpler since we can just extract regional format settings from the built-in system cultures.

Isn't Discord's approach also based on your application language? That's why I proposed English, German and so on as presets.

Allowing the user to configure each separate format adds complexity, isn't future-proof (what if another format appears?), and I doubt there will be many people who will actually want to do that.

Yeah, I totally agree.

[Tyrrrz]

Isn't Discord's approach also based on your application language? That's why I proposed English, German and so on as presets.

Yeah, it lets you pick a language, but the date formats are still probably extracted from the system for the specified locale. In other words, when you choose German, it looks up the list of system locales to find the matching date format for the German locale. I doubt the application stores its own database for this purpose.

In our case, we'd just need to surface a drop-down to select one of the locales available in the system and use all the formatting setting stored within in. No need to make our own database.

[zabszk]

In our case, we'd just need to surface a drop-down to select one of the locales available in the system and use all the formatting setting stored within in. No need to make our own database.

Isn't it better to just let the user provide the format (or just add "Custom" to the list of locales)? It gives the user more flexibility and as far as I know there is no locate that uses UTC timestamps. Being able to use timestamps in UTC is really important (and was requested in the past by other users as well, eg. #287). If you work in international team u is the only usable time format, because having a different timezones (which are not known!, DCE doesn't log them anywhere in the export files) in multiple exports makes them quite useless.

That's why I think that we should keep the ability to manually input the timestamp format or at least provide the ability to use any format using UTC (eg. u format).

I think the easiest way is to just use the system default timestamp format (from the OS) unless the user explicitly overrides it with a custom one. We can make the "Date format" textbox empty by default and add an explanation that empty textbox means OS default format.

[Tyrrrz]

Isn't it better to just let the user provide the format (or just add "Custom" to the list of locales)? It gives the user more flexibility and as far as I know there is no locate that uses UTC timestamps.

At the moment, we're using at least 8 different date formats at once, so no, providing them wouldn't be easier. The current textbox only controls one of the formats, which is the one used for message timestamps. The vast majority of users will not want to configure so many options.

It would be easier to create an "invariant" locale that would format dates in an unambiguous format and at UTC+0.

[zabszk]

At the moment, we're using at least 8 different date formats at once, so no, providing them wouldn't be easier. The current textbox only controls one of the formats, which is the one used for message timestamps. The vast majority of users will not want to configure so many options.

It would be easier to create an "invariant" locale that would format dates in an unambiguous format and at UTC+0.

Fair point, it might be a better idea.

[CanePlayz]

Yeah, it lets you pick a language, but the date formats are still probably extracted from the system for the specified locale. In other words, when you choose German, it looks up the list of system locales to find the matching date format for the German locale. I doubt the application stores its own database for this purpose.

Are you sure? No matter what I've changed in Windows, Discord formatted the timestamps solely based on my application language.

[Tyrrrz]

Yeah, it lets you pick a language, but the date formats are still probably extracted from the system for the specified locale. In other words, when you choose German, it looks up the list of system locales to find the matching date format for the German locale. I doubt the application stores its own database for this purpose.

Are you sure? No matter what I've changed in Windows, Discord formatted the timestamps solely based on my application language.

Yes, but the region format options are pulled from the locale database installed on your system.

[CanePlayz]

Yes, but the region format options are pulled from the locale database installed on your system.

Oh, now I get it, my bad.

[CanePlayz]

I think the embed timestamps have the same format regardless of user settings. I believe you pointed it out in the past: #648

Either Discord has changed this or I was wrong back then, but they're definitely being formatted differently based on the user's locale now.