Server: can't set date/time format to `%Y-%m-%d %H:%M:%S`

Created on 5 May 2019  路  20Comments  路  Source: nextcloud/server

Steps to reproduce

  1. Open Settings page
  2. Set language to English (US)
  3. try setting locale as follows:
    %Y-%m-%d %H:%M:%S eg.: 2019-04-07 16:07:17
    and week starting Monday

/ref https://help.nextcloud.com/t/language-locale-mixup/51123

Expected behaviour

It should be possible to set date/time format as %Y-%m-%d %H:%M:%S and the starting day of the week to Monday.

Actual behaviour

It is not possible to set the date/time format as %Y-%m-%d %H:%M:%S and the starting day of the week to Monday.

Context

It seems that certain apps make use of the locale setting. However, the Files app does not (The date looks different when hovering over the relative modification time.)
But the calendar app uses the start day and the date/time setting.
Either way, it is very annoying that I can't set the date and time to the most standarized format ever: the ISO format. The only way seems Esperanto, but then the language in the calendar changes as well. So somehow there's a weird mixup of language and locale.

Server configuration detail

Operating system: Linux

Webserver: Apache/2.4.39

Database: mysql 5.6.25

PHP version:

7.2.18
Modules loaded: Core, date, libxml, openssl, pcre, sqlite3, zlib, bcmath, bz2, calendar, ctype, curl, dom, hash, fileinfo, filter, ftp, gd, gettext, gnupg, SPL, hkct, ibm_db2, iconv, session, intl, json, mbstring, standard, mysqlnd, pcntl, PDFlib, mysqli, PDO, pdo_ibm, pdo_mysql, pdo_sqlite, Phar, posix, readline, Reflection, imap, shmop, SimpleXML, sockets, exif, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, zip, cgi-fcgi, apcu, imagick, mongodb, igbinary, sodium, redis, mcrypt, luasandbox, Zend OPcache

Nextcloud version: 15.0.7 - 15.0.7.0

Updated from an older Nextcloud/ownCloud or fresh install: updated from 14.0.10

Where did you install Nextcloud from: updater.phar

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.1.0
 - activity: 2.8.2
 - admin_audit: 1.5.0
 - announcementcenter: 3.4.1
 - apporder: 0.6.0
 - bookmarks: 1.0.2
 - bruteforcesettings: 1.3.0
 - calendar: 1.6.5
 - cloud_federation_api: 0.1.0
 - comments: 1.5.0
 - contacts: 3.1.1
 - dav: 1.8.1
 - federatedfilesharing: 1.5.0
 - federation: 1.5.0
 - files: 1.10.0
 - files_external: 1.6.0
 - files_pdfviewer: 1.4.0
 - files_sharing: 1.7.0
 - files_texteditor: 2.7.0
 - files_trashbin: 1.5.0
 - files_versions: 1.8.0
 - files_videoplayer: 1.4.0
 - firstrunwizard: 2.4.0
 - gallery: 18.2.0
 - issuetemplate: 0.5.0
 - logreader: 2.0.0
 - lookup_server_connector: 1.3.0
 - nextcloud_announcements: 1.4.0
 - notes: 2.6.0
 - notifications: 2.3.0
 - oauth2: 1.3.0
 - password_policy: 1.5.0
 - phonetrack: 0.5.0
 - provisioning_api: 1.5.0
 - serverinfo: 1.5.0
 - sharebymail: 1.5.0
 - systemtags: 1.5.0
 - tasks: 0.9.8
 - theming: 1.6.0
 - twofactor_backupcodes: 1.4.1
 - twofactor_totp: 2.1.2
 - twofactor_u2f: 2.1.3
 - updatenotification: 1.5.0
 - workflowengine: 1.5.0
Disabled:
 - activitylog
 - encryption
 - files_markdown
 - support
 - survey_client
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "15.0.7.0",
    "installed": true,
    "forcessl": true,
    "loglevel": 2,
    "maintenance": false,
    "trusted_domains": [
        "***REMOVED SENSITIVE VALUE***"
    ],
    "share_folder": "\/Shared",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "logdateformat": "Y-m-d H:i:s O",
    "logtimezone": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpmode": "sendmail",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpsecure": "ssl",
    "memcache.local": "\\OC\\Memcache\\APCu",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "port": 0,
        "timeout": 0
    },
    "appstore.experimental.enabled": true,
    "trashbin_retention_obligation": "auto",
    "updater.release.channel": "production",
    "htaccess.RewriteBase": "\/",
    "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
    "auth.bruteforce.protection.enabled": false,
    "theme": "",
    "mail_smtpauthtype": "PLAIN",
    "mail_smtpauth": 1,
    "mail_sendmailmode": "smtp"
}

Are you using external storage, if yes which one: No

Are you using encryption: No

Are you using an external user-backend, if yes which one: No

Client configuration

Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Operating system: macOS 10.14.4

Logs

Nothing in the logs.

enhancement

All 20 comments

Thanks for the info. Yes, it looks like they are related, but I don't think that either of those would solve my problem, since there's no locale which has the format %Y-%m-%d %H:%M:%S with week start day Monday.

@tessus So isn't this rather a feature request for setting a custom datetime format than a bug?

@wiswedel I'd usually agree, but not when it comes to the most standardized format ever - ISO 8601.
If a system isn't capabale of showing date/time in ISO 8601, it is a bug.

If a system isn't capabale of showing date/time in ISO 8601, it is a bug.

Let's not argue about labels.

Which way do you want to proceed with?

  1. Feature request for a locale "ISO 8601"
  2. Feature request for a custom datetime setting per user

I don't care as long as the time/date format is %Y-%m-%d %H:%M:%S and the week starts on Monday.

@wiswedel But you should be aware that "labelling" this as a feature request is pretty much the same as closing this issue. Since I'm not a paying customer this won't be looked at. I'll ping you in 3 years and ask you about this issue.

@tessus Just keeping it labelled as "bug" doesn't speed up things either.

But here's the upside: Feel free to contribute the feature yourself. You seem pretty fit to do so. This is open source and not MS Office, you don't have to wait for "the company" to catch up with your request 馃槈

@wiswedel I would, but I have no idea where to start. The code base is huge and I'm not a javascript person. I know how to code in PHP, but I have no idea how that is glued to the UI with JS.

I've been meaning to write 2 nextcloud apps for a while now, but without any help this is impossible, especially since JS is required. So I doubt that I'm much of any help at all.
I hope that I can invest some time looking into these things, but until then I depend on others to do the coding.

CC @schiessle

ping

@wiswedel you made a mistake. my ticket can't be a duplicate of something that was created after mine.
So 15437 is a duplicate of 15381.
You do understand the concept of cause-and-effect, don't you?

@wiswedel you made a mistake. my ticket can't be a duplicate of something that was created after mine.
So 15437 is a duplicate of 15381.
You do understand the concept of cause-and-effect, don't you?

@tessus No reason to react offended, is it? Just doing some housekeeping on the tickets and breaking down stories in order to get them addressed as efficiently as possible - which should be in everyone's interest.

@wiswedel Offended? I was stating a fact.

Are you offended by me asking you, if you understood causality and/or sequence theory?
I stated that you made a mistake. Which is true. I explained it. And then I asked you, if you understood my explanation. So why should I be offended?

Just doing some housekeeping on the tickets and breaking down stories in order to get them addressed as efficiently as possible

I'm not denying that. I'm just saying that my issue can only be a duplicate of something that had been created before my issue.

Seriously, what is this? Kindergarden? Any logical thinking person would have said: "Thanks for pointing this out, re-opened the issue, and closed the real duplicate." Deflecting doesn't make it any better. I get it that you might think that there's an undertone. There isn't. It's just plain facts. Period.

(If I told you that it was a sunny day, would you interpret it as if I didn't enjoy the sun?)

P.S.: Anyway, do what you want. It's not gonna change anything anyway. Hmm, maybe in a few years this will be sold as a great new feature. Until then, people can't use the format that makes the most sense (by eliminating any possibilitty of ambiguity). I'm sorry but the current SW design is a joke and what's more embarrassing is that it isn't even recognized.
Do me a favor and don't see/interpret the last paragraph as a personal attack. It isn't. It is my opinion and has nothing to do with you.

Denmark locale should have %Y-%m-%d %H:%M:%S format, but for some reason it has %m/%d/%Y format.

$ LC_TIME=en_US.UTF-8 date
Tue 28 Apr 2020 09:39:24 AM UTC

LC_TIME=en_DK.UTF-8 date
2020-04-28T09:39:30 UTC

You're right, @redmosaic . For this reason I've just opened #24134, which addresses this.

This is all very nice, but I think it is very strange that there's no single locale that allows me to have an ISO date format with a 24h clock + Monday as the start of the week.

IMO this is ridculous. Most SW allows me to set the date/time preferences manually. Nextcloud, which I wsa told is the greatest and best, can't do it? And then my issue is closed in favor of a ticket that was created AFTER mine, which does not even address the bug I have opened. Another proof of mismanagement and wrong priorities.

There was a statement during the virtual Nextcloud event where someone said that basic features are ignored and long-standing issues concerning the core are not addressed. @karlitschek looked perplexed and didn't know what was meant by that.
This issue is a perfect example. (Although this one is not that old - just 1.5 years, there are others that are several years old.)

Was this page helpful?
0 / 5 - 0 ratings