I have a timestamp field that is suppressing the "00" value when seconds are 0.
Example:
Notice that 04:36 PM does not show the 00 seconds.
Here's my field formatting:
Is there some way to get it to always display "00" for seconds when the timestamp falls exactly on 0 seconds?
Edit to add:
Check your date format. If the date format is "as entered" then it ignores the time formatting. So set date format to something like "dd/mm/yyyy" and you'll see time format be respected.
Claris warns against using the Classic Theme. It is used when converting old files that didn't have themes. Unfortunately last time I tried to find the document on Claris web site, I was not successful 
.
Interesting - using @weetbicks trick I can now see the proper formatting, but only in a Body layout part. In the Table view portion, it's still wrong:
So it looks like two issues:
It's all fine for Claris to say not to use Classic theme. The issue however is a lot of legacy solution layouts were at one point in time built on top of Classic theme. Even if the theme has since been saved to a new one, with their own styles - the underlying core of the theme is Classic - making it exhibit all the classic issues.
So the Classic Theme may still be inside the file, which would be enough to trigger the warning. The only way to get rid of the Classic Theme is then to make sure no Layout use the Theme and to remove the Theme from the file I guess.
I don't think that is the issue. The classic theme, in terms of the CSS, doesn't have inherent problems. I've attached a copy of the CSS so that you can see what is inside.
The issue is that you cannot save changes to classic theme. What many people did was to start using local styles on top of classic themes. If you used any other theme you could setup your defaults to cover the 80% of your needs, and have custom styles handle the rest. That means the CSS is pretty lean, and easy to implement. With Classic, all of the styling was local to each object. Every single object had to carry the style instructions to override the Classic object style. First of all, this increases the layout payload enormously. Each layout could have a megabyte or more of local styles. Then there was the rendering, because the initial rendering pass would be Classic theme, then each object had to be rendered with it's local style. That was the real gotcha.
ClassicTheme.txt (23.3 KB)
No don't do this! Even if no layout uses classic theme, you should not delete it. I know Claris have added in the ability to remove Classic, but I did attempt this on an older solution. I had created a new theme (whose objects were at once point based on classic)
Even when no layout used classic specifically, the act of deleting classic destroyed every layout . Simply saving a new theme based on classic is not enough to allow you to completely disconnect that theme from classic, there are still elements that use classic underneath it all....
This is why the delete classic option is very dangerous for legacy solutions. The only safe situation to delete it is if your solution has no layouts in it whose theme was ever based on Classic.
Oh my giddy aunt! Dumb luck is all that stood between me and that.
Looks like Classic Theme is with us till the end of times. Is it that other themes refers to Classic ?
No. The @weetbicks anecodote that themes based on Classic continue to contain back references to Classic is news to me. I'm going to have to experiment for myself to see it in action.
This is already happening. FileMaker shipped without Classic in a version (or two?) back. This is causing a new problem for us. We provide a file of layout templates, many dozens of them, and allow full access for user to generate their own reports. All of the layouts are based on Classic and this has one advantage: Classic does not allow changes to the theme. This prevents users from accidentally modifying all of the templates. Now we will have to preserve Files that do contain a Classic theme. We've already asked Claris to provide some way for us to lock a theme, in the same way that they locked Classic.
Very interesting !
I can be more specific on the exact nature of the issue removing Classic.
So the issue affects any object on any layout (of any theme supposedly based on classic) which uses the "Default" style - possibly unsaved but not 100% on that.
The "Default" must be using elements from classic (perhaps if unsaved) and so the deletion of classic theme breaks any object on any layout using default. Again this is likely if default has not been saved to the theme.
I noticed this in a large solution after deleting classic. However my solution was mostly styled, and so I didn't notice it on main screens. It was only days later when I checked a print-based layout that I noticed every object was actually not rendering. This was any object unsaved default style.
The reason this occurred is back int the day as part of removing 'classic' I applied a new theme to layouts. The trick in doing so was cut the layout objects, change theme, paste the layout objects back, and then cmd+z do undo will revert applied styles from the new theme, and display objects in their original formatting. So technically the layout was baesd on the new theme but the objects were unsaved default style - turns out these were likely still linked to the classic theme directly...
Fast forward, to deleting the classic theme altogether and any default unsaved style broke. Here is a before and and after:
This caused me a massive headache. My solution was to basically roll back to a clone and DMT. I had no option of reimporting classic. Any attempt to copy/paste contents of every layout back onto the layouts of a clone were unsuccessful and left every object unstyled....
So... cautionary tale !! You might be OK if you can be confident every object on every themed layout has a saved style, but beware of any that use default style - especially unsaved.
