La manera más simple de hacerlo es con un Property Change Listener:

Desde el ActionPerformed del botón se dispara un PropertyChangeListener del contenedor, Calendario, que supongo será un JPanel, con los datos que se quieran propagar: ese String o Date con la fecha.

En el JFrame que inicializa el Calendario, una instancia de éste último registra un PropertyChangeListener.

Como este tipo de listener usa un String como identificador de eventos, es fácil conocer cuál se ha disparado desde el botón, y procesarlo como convenga en el JFrame.

http://docs.oracle.com/javase/tutorial/uiswing/events/propertychangelistener.html

El PropertyChangeSupport solo se usa cuando la clase no lo tiene por defecto. Con componentes de Swing no es necesario.
Por otra parte, siempre hay que tener mucho cuidado sobre quién dispara y quién recibe los eventos.

Es fácil confundirse y disparar el evento del PropertyChange del botón, en vez del contenedor, si se usan clases anónimas para los ActionListener, por ejemplo.

En el JFrame, quién debe registrar los eventos es la instancia de la clase Calendario, que si es un componente de Swing ya tiene incluido el PropertyChangeSupport.

public class Panel extends javax.swing.JPanel {

/** Creates new form Panel */
public Panel() {
initComponents();
jButton1.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
Panel.this.firePropertyChange("boton1", null, "Soy el boton 1");
}
});
jButton2.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
Panel.this.firePropertyChange("boton2", null, "Soy el boton 2");
}
});
}

/** This method is called from within the constructor to
initialize the form.
WARNING: Do NOT modify this code. The content of this method is
always regenerated by the Form Editor.
*/
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated Code">
private void initComponents() {

jButton1 = new javax.swing.JButton();
jButton2 = new javax.swing.JButton();

jButton1.setText("jButton1");
add(jButton1);

jButton2.setText("jButton2");
add(jButton2);
}// </editor-fold>
// Variables declaration - do not modify
private javax.swing.JButton jButton1;
private javax.swing.JButton jButton2;
// End of variables declaration
}

public class Frame extends javax.swing.JFrame {

public Frame() {
initComponents();
jPanel1.addPropertyChangeListener(new PropertyChangeListener() {
@Override
public void propertyChange(PropertyChangeEvent evt) {
switch (evt.getPropertyName()) {
case "boton1":
System.out.println(evt.getNewValue());
break;
case "boton2":
System.out.println(evt.getNewValue());
break;
}
}
});
}

/** This method is called from within the constructor to
initialize the form.
WARNING: Do NOT modify this code. The content of this method is
always regenerated by the Form Editor.
*/
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated Code">
private void initComponents() {

jPanel1 = new Panel();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
getContentPane().add(jPanel1, java.awt.BorderLayout.CENTER);

pack();
}// </editor-fold>

/**
@param args the command line arguments
*/
public static void main(String args[]) {

java.awt.EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
new Frame().setVisible(true);
}
});
}
// Variables declaration - do not modify
private javax.swing.JPanel jPanel1;
// End of variables declaration
}

Ese es un ejemplo ejecutable que muestra la manera de lograrlo.

En ese caso el JLabel debería ser visible fuera del contenedor, para poder registrar sus propios eventos.
Es una cuestión de encapsulación: si el contenedor es el único visible, debe procesar todos los eventos que lancen sus componentes internos.
El problema de hacer accesibles los componentes, es que puede modificarse su comportamiento desde cualquier clase que los "vea", tanto intencionadamente como por error.
Puesto que los PropertyChangeListener tienen una "etiqueta", es fácil conocer qué componente los ha disparado. El hecho de que los eventos los registre el contenedor, no le convierte en "propietario" de los mismos, sino en un vehículo para su procesamiento.

Por todo ello, es perfectamente lógico que haya un único registro de eventos por parte del contenedor, para mantener la correcta encapsulación de sus componentes internos, que a su vez también son propiedades privadas del contenedor.
En realidad, cuando el contenedor dispara un evento, lo que hace es exponer al exterior (mediante su listener), que una propiedad suya (un componente en este caso) ha cambiado.

He vuelto a releer todos los comentarios, porque algo no me cuadraba del todo.
Ese JLabel que mencionas está en el JFrame, por lo que he leído, y no forma parte del contenedor del Calendario.
En este caso, no tiene sentido que el JLabel registre su propio listener para escuchar eventos del Calendario, porque no tiene ninguna relación con él.
El objeto del PropertyChangeListener es que una clase pueda escuchar eventos propios desde sus instancias en otras clases diferentes, por las razones expuestas en el comentario anterior.
Si ese JLabel es ajeno al contenedor Calendario, no puede escuchar eventos disparados en éste último.
Si el JLabel necesita modificarse, en función de eventos de Calendario, debe hacerlo dentro del listener de Calendario, que es quien "comunica" a la clase donde está instanciado, el JFrame, que sus propiedades han cambiado.

No, eso no lo hace Swing, ni el JDK. No disponen de un "buzón global" donde enviar mensajes y desde donde recibirlos.
Eso lo hacen librerías externas como EventBus, o Guava (más limitado que EventBus), que implementan el patrón Publisher/Subscriber.