Switching between two modes
The most obvious solution is to have toggle buttons, a dropdown, or a View menu item the switches between the two modes. This is especially preferred if the two modes tend to be used by two different user groups, rather than each user tending to switch among modes. Preserve the mode selection between sessions and the average user only has to select the mode once in a long time. The default date for one mode can be a date from the other mode, the exact value being determined by user research. For example, you may find that users usually need to see a bar graph for the latest date from the detail line graph, so that becomes your default date for the bar chart.
On the other hand, maybe users usually want to see both a detail line graph and a bar graph in a single session. If users generally want to see a bar graph for a specific spot in the detail line graph that looks interesting, then let users select that point on the detail line graph, which then pages them to the bar graph; that is, users “drill down” from the detail line graph to the bar graph. A Back button returns the user to the detail line graph.
User research may show that the order of use of the two graphs is not so clear cut. If that’s the case, then rather than making users switch between modes, show both the detail line graph and bar graph at the same time in two frames above the master chart. Unless you have cases where there are many variables tracked (which would make your line graphs unreadable), the bar graph can be quite narrow, so you should be able to steal a little real estate from the detail line graph and put the bar graph beside it. As dictated by user research, the bar graph may always show the latest date (or earliest date or midpoint date) of the detail line graph, or it has its own user-specified date –maybe even going outside of the range of time depicted in the detail line graph.
To save both real estate and UI complexity, considering combining the line graph and bar graph functionality into a single mode and frame. Maybe when the user enters the same date for Start and End for the detail line graph, the detail graph switches to a bar graph. Or, for visual consistency, the line graph shrinks to become a “dot graph” with a vertical stack of dots representing the values of the variables, which has the same information as a bar graph. Come to think of it, why do users need a bar graph at all? The line graphs already show the differences in the variables at a specific (every) time. Dig beneath the requirement, and you may find that what users really want is the precise absolute variable values for a precise point in time. Maybe what you really want is to numerically show the variable values for a user selected time point, perhaps super imposed over the detail line graph, or perhaps in a small table to the side, perhaps integrated with the legend.
Selection box for the bar graph
I’d guess you do need a text box for the bar graph date. I’d expect user research will tell you that users want a very precise date for the bar graph and thus need to see (and possibly adjust) the date it represents. However, I'd also show the bar graph’s date as a vertical line (with more contrast that you’re showing) on the line graph(s) to visually relate the graphs.
Select the bar graph date
I’d include the ability to select dates by clicking/touching a spot on a line graph (or dragging a vertical line, if a direct click/touch is used for something else). To allow greater precision, consider having the user select the bar graph date from the detail line graph (i.e., “drilling down” as in Option 2, or making the table/bar graph a detail of the detail line graph for Option 3 or 4).
User research will probably show that users tend to want “round” dates (e.g., first of the month, end of the week). If so, then let the click/touch “snap” to the nearest round date. If there are often cases when users don't want a round date (e.g., they want to select a peak in one varible), then snap-to can be mode to turn on and off with the menu, and/or a meta-mode (e.g., Alt-clicking has no snap-to).
With or without snap-to, for a mouse interface, you can highlight (with a vertical line) the date the mouse is hovering over so the users see what they're about to select. This shows what snap-to will snap to, so users won't make errors, and, with snap-to off, users can more easily point precisely to that peak in Variable A before selecting. In any case, let the user hold the mouse button down and drag a little to finely adjust the date (provide graphic and numeric feedback), "overriding" any snap-to.
In a touch interface, you may be able to let the user adjust the precise date by the user holding the finger on the line graph and "rocking" the finger left or right to increment the selected date up or down, providing feedback graphically and numerically. I imagine that would be pretty intuitive, but it should be tested.
Beyond that, include an editable text box for any date so users can always type in exactly what they want or select it from a calendar control. You may also want to include spinner buttons so users can make fine adjustments (e.g., incrementing by day) for whatever they select from the line graph. That should have better discoverability than "micro-drags" or "rocking" or meta-modes. A dropdown for the bar graph with common choices (like you helpfully have for the detail line graph), may also be worth the added clutter.
