Feature Request for Time / Date Format

I would like to request that both the time and date format used in DO be configurable separate from that used in Windows.

Thank you.

Can you give us an idea of a situation where you'd want Opus to use different date/time formats to the rest of the system?

(The main thing I can think of is already covered, where you can specify whether or not to show seconds in times. The other details, like 12 or 24 hour time and short date format seem like things you'd want the same everywhere.)

[quote="leo"]Can you give us an idea of a situation where you'd want Opus to use different date/time formats to the rest of the system?

(The main thing I can think of is already covered, where you can specify whether or not to show seconds in times. The other details, like 12 or 24 hour time and short date format seem like things you'd want the same everywhere.)[/quote]

First off the best reason is that this is the way I prefer to work when doing file and folder maintenance. Period.

Secondly, it is never a good idea to change any of Windows default settings. Way too often in the Windows world changing things from the defaults causes things to break. Case in point, I changed the date / time format temporarily and within minutes programs began to break (I added the arrows for emphasis):

[code]HP Error ID: -2146233033 at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at System.DateTime.Parse(String s, IFormatProvider provider)
at HP.SupportFramework.Utilities.HPSAIssues.ActionItemCollection.loadActiveCheckResult(Boolean includeIgnored)
------>>>> Message: String was not recognized as a valid DateTime. <<<<------
StackTrace: at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at System.DateTime.Parse(String s, IFormatProvider provider)
at HP.SupportFramework.Utilities.HPSAIssues.ActionItemCollection.loadActiveCheckResult(Boolean includeIgnored)
Source: mscorlib

Name: HPSF.exe
Version: 07.00.01.01
Path: C:\Program Files (x86)\Hewlett-Packard\HP Support Framework\HPSF.exe
Format: en-US
RAM: 15836
Ram Utilization: 20
TargetSite: System.DateTime Parse(System.String, System.Globalization.DateTimeFormatInfo, System.Globalization.DateTimeStyles)
[/code]

The above error was something totally unexpected but nonetheless predictable given Microsoft's long history of building in quirks, inexplicable malfunctions, and outright failures. In this case it is actually a problem with some HP voodoo programming but the point remains, I would rather have the ability to change things like this in a program that is under much tighter and more professional control, this way only DO would act screwy if things go wrong rather than the whole system blowing up. :grin:

Please reconsider my request.

As someone in the UK (different DD-MM-YYYY order to the USA), who changes the short date format from the defaults (so it's like 14/Dec/2013 instead of 14/12/2013), I'm aware that some software has issues with different date formats as it's only tested with the default US ones. However, it is not a lot of software because a huge number of people out there use non-US date formats.

If other programs break when you set Windows to use your prefered date format, why not complain and get those programs fixed? (Especially from a massive vendor like Hewlett-Packard who sell their products worldwide.)

Their developers probably don't realise and will want to fix the problem because it means their programs are broken for people in large parts of the world (since the default date formats in Windows are not the same everywhere). It is trivial to fix date parsing issues like that (they just need to add/change one argument in their System.DateTimeParse.Parse call, which is probably failing for users in every country except the USA right now).

I think getting broken software fixed makes more sense than keeping the system-wide setting as something you don't want it to be and asking everyone who writes software that displays dates to provide an app-specific override.