How can I change the appearance (e.g. colour) of the arrows in the QDateEdit object in QtDesigner?

I have a problem with changing the appearance of the QDateEdit object. I can normally change parameters such as border, border radius and padding left, but I cannot change at least the colour of the arrows. Is there any way to fix this?

QDateEdit QAbstractSpinBox::up-arrow {
    background-color: white;
    border: none;
}

QDateEdit QAbstractSpinBox::down-arrow {
    background-color: white;
    border: none;
}

QDateEdit QAbstractSpinBox {
    border: none;
}

QDateEdit {
    border: 2px solid #6D9886;
    border-radius: 8px;
    padding-left: 10px;
}

It seems to me that the following actions follow from this code:
the border colour changes (what happens)
the width of the border changes (what happens)
the colours of the arrows change (which does not happen)
arrow borders change (which does not happen)

There are two important aspects when dealing with QSS (Qt Style Sheets).

The first one is that, when dealing with complex widgets, one should always remember the following note about sub controls:

> Note: With complex widgets such as QComboBox and QScrollBar, if one property or sub-control is customized, all the other properties or sub-controls must be customized as well.

This means that, whenever a complex widget has a QSS rule that might alter sub-control appearance, ALL properties of that control should be properly set.

<hr>

Unfortunately, your style sheet has fundamental flaws.

Most importantly, the rules based on the following are not valid:

QDateEdit QAbstractSpinBox[whatever] {
   ...
}

The reason is that you're using the "Descendant Selector":

The above means that you're setting a rule for any QAbstractSpinBox that would be a child of a QDateEdit: that's wrong, because QDateEdit inherits from QAbstractSpinBox, so the spinbox is the QDateEdit, not its child.

<br>
Then, there's the issue about specifying all properties.

Unfortunately, as said above, whenever you set a complex widget rule that affects its geometry, you need to specify all properties related to its sub controls. And, since setting the above properties will clear the display of the QAbstractSpinBox arrow buttons, you have to explicitly set them.

As the examples show, the convention is to specify image files for the arrow icons, which leads us to the second problem.

QSS were developed with the original CSS 2.1 implementation, a time in which pixel density was not that important in computer screens.
While Qt is normally capable of converting px units in High DPI screens, this doesn't always consider the relation with text display, which is extremely important if the screen uses font scaling. This is also valid when specifying image resources: unless you provide scalable images (aka: svg files), the icons might have wrong sizes (almost invisible, or extremely big), and even in that case, the style sheet should be properly customized and tested considering these aspects.

So, there are only three possibilities:

1. just stick to the default appearance (usability is much more important than appearance!);
2. provide (and properly test) custom scalable images for the arrows;
3. ignore any DPI related aspect, and use the below trick;

The 3rd possibility uses a common trick (see this related post) that can be used as arrow icons: create an empty content and use fake CSS borders, with the "arrow" being the only visible border opposite to the arrow direction.

Note that you must consider the following aspects:

• the default "transparent" border must be set with rgba(255, 255, 255, 0) and not transparent (which is has 0-rgb components and won't overlay the other borders at all);
• QSS requires that all widget lengths must be in px units, meaning that you might have issues as explained above (so, no, it's not guaranteed to work everywhere);
• in order to ensure proper QSS management, the widget should use the fusion style: dateEdit.setStyle(QStyleFactory.create('fusion'));
• the arrow color should be consistent with the widget background; from your code and screenshot it is not clear if the "gray" background is manually/programmatically set, but you can never ignore that aspect, otherwise you will make important UI elements almost or completely invisible to the user; consider using the palette() syntax in CSS.

Here is the corrected and updated QSS that could be used to get the wanted result:

QDateEdit {
    border: 2px solid #6D9886;
    border-radius: 8px;
	padding-left: 10px;
}

QDateEdit::up-button, QDateEdit::down-button {
	border: none;
	padding-right: 5px;
}

QDateEdit::up-button {
	subcontrol-position: top right;
}

QDateEdit::down-button {
	subcontrol-position: bottom right;
}

QDateEdit::up-arrow, QDateEdit::down-arrow {
	border: 5px solid rgba(255, 255, 255, 0);
	width: 0;
	height: 0;
}

QDateEdit::up-arrow {
	border-top: none;
	border-bottom-color: white;
}

QDateEdit::down-arrow {
	border-bottom: none;
	border-top-color: white;
}

^{Considering the above suggestion, please take a look at the update below.}

I strongly recommend you to look at the QSS examples, reference and syntax, and also take your time (a lot of it) to make experiments and tests in order to understand how the above works. Also, never underestimate the studying of source code (starting with this code browser, which is wonderfully done and extremely educational).

<hr>

Finally, remember that, as powerful and extensible (and, to be honest, not always reliable) the QSS framework is, it should always be used with care and awareness. The QtWidget module was created and intended for usage in a period where screen visualization was quite standardized, and the main priority was always usability and full widget visibility, as the UI didn't need to be fancy if it wasn't usable (actually, that should be a fundamental rule of thumb, but that's a bit off topic).

Making the UI "good looking" is fine, but never lose the usability aspect, which should always have absolute priority. People won't care if the UI is fancy, if they're not able to properly use it.

A more appropriate QSS

Since the stylesheet should always consider the state of interactive elements and, as much as possible, the current palette, you should consider the following aspects:

• the widget should always try to use the default palette (the one of the current QApplication, meaning the one retrieved from the OS or that explicitly set using QApplication.setPalette()), otherwise the contents of the widget might become invisible;
• interactive elements should always show hints to the user: the most important aspect is the enabled/disabled state of the widget, but mouse hover or window active state should be considered as well;

With the above in mind, I'll suggest the following QSS, assuming that a proper QSS or QPalette was set on the QApplication. Most importantly, even considering the extensible nature of QSS features, the application QPalette is of extreme importance. So, unless you are going to explicitly set an extensive QSS rule that is application-wide, you should primarily set a basic QPalette for the application and eventually alter its colors based on that assumption.

As long as a proper QPalette is set (including appropriate colors for roles such as QPalette.Base and QPalette.Text), the following QSS will be valid and user intuitive:

QDateEdit {
    border: 2px solid #6D9886;
    border-radius: 8px;
    padding-left: 10px;
}

QDateEdit::up-button, QDateEdit::down-button {
    border: none;
    padding-right: 5px;
}

QDateEdit::up-button {
    subcontrol-position: top right;
}

QDateEdit::down-button {
    subcontrol-position: bottom right;
}

/* now, the magic begins */

QDateEdit::up-arrow, QDateEdit::down-arrow {
    /* a default color for the "border" (aka, the arrow) */
    border: 5px solid palette(button-text);

    /* right and left borders will be transparent */
    border-left-color: rgba(255, 255, 255, 0);
    border-right-color: rgba(255, 255, 255, 0);

    /* basic "null" size as above */
    width: 0;
    height: 0;
}

/* set up the up arrow states */

QDateEdit::up-arrow {
    /*
        we want to show the "down border" alone, so we make the 
        opposite one (the top) invisible and **empty**
    */
    border-top: none;
}

QDateEdit::up-arrow:hover {
    border-bottom-color: palette(highlight);
}

QDateEdit::up-arrow:pressed {
    border-bottom-color: palette(text);
}

QDateEdit::up-arrow:disabled, QDateEdit::up-arrow:off {
    /*
        use the "mid" color role as a disabled/invalid arrow
        state; since this rule is stated *after*, it will take
        precedence in case it matches;
    */
    border-bottom-color: palette(mid);
}

/*
    set up the down arrow states, similarly to the above, but
    using the opposite border when relevant.
*/

QDateEdit::down-arrow {
    border-bottom: none;
}

QDateEdit::down-arrow:hover {
    border-top-color: palette(highlight);
}

QDateEdit::down-arrow:pressed {
    border-top-color: palette(text);
}

QDateEdit::down-arrow:disabled, QDateEdit::down-arrow:off {
    border-top-color: palette(mid);
}