GUI - Date/Time Column readability

[Mesh]

Here is a small GUI suggestion regarding date/time columns.


All of the Date/Time columns are very difficult to read and parse (especially if you're working with a large number of files) because the date and time are so close to each other. Not only that, but if you're not using date and time formats that use leading zeroes, nothing lines up, and it's all quite a bit worse.

I propose formatting all of the date/time columns so that the dates are all left justified, the times are all right justified, and adjusting the column width allows you to change the space in between.


For example:


Before:

Code: Select all

With Leading Zeroes:

2007-01-10 08:27:19
2007-11-03 20:13:44
2005-12-07 01:56:13
2007-05-08 14:12:56
2009-12-23 03:38:38
2007-02-01 15:44:22
2008-11-17 00:56:10
2008-06-11 20:01:19
2004-08-01 17:25:49
2008-10-30 04:21:51


Without Leading Zeroes:

1-10-2007 08:27:19
11-3-2007 20:13:44
12-7-2005 01:56:13
5-8-2007 14:12:56
12-23-2009 03:38:38
2-1-2007 15:44:22
11-17-2008 00:56:10
6-11-2008 20:01:19
8-1-2004 17:25:49
10-30-2008 04:21:51

---------------------------------------
After:

Code: Select all

With Leading Zeroes:

2007-01-10   08:27:19
2007-11-03   20:13:44
2005-12-07   01:56:13
2007-05-08   14:12:56
2009-12-23   03:38:38
2007-02-01   15:44:22
2008-11-17   00:56:10
2008-06-11   20:01:19
2004-08-01   17:25:49
2008-10-30   04:21:51


Without Leading Zeroes:

1-10-2007    08:27:19
11-3-2007    20:13:44
12-7-2005    01:56:13
5-8-2007     14:12:56
12-23-2009   03:38:38
2-1-2007     15:44:22
11-17-2008   00:56:10
6-11-2008    20:01:19
8-1-2004     17:25:49
10-30-2008   04:21:51

What do you think?

[j_c_hallgren]

I'll throw in my $.01!

Personally, I have my setup as "mm/dd/yyyy hh:mm:ss" so the issue of 'wiggly' cols doesn't occur, and I don't see why anyone would use a setup that does...but...I do agree that at times, being able to expand the blank space between the date & time would make quick reading a bit easier, and I can't think of any reason why your idea isn't practical or would negatively affect existing users.

[Mesh]

Personally, I have my setup as "mm/dd/yyyy hh:mm:ss" so the issue of 'wiggly' cols doesn't occur, and I don't see why anyone would use a setup that does...but...I do agree that at times, being able to expand the blank space between the date & time would make quick reading a bit easier, and I can't think of any reason why your idea isn't practical or would negatively affect existing users.

The only catch that would have to be accounted for is what to do if a user shrinks the column too much, in which case I would recommend setting the space between date and time to a minimum of one space, after which the column truncates from the right - as it does now.

[jacky]

Well, what you're saying makes sense, but then at the same time why would you use such a format anyways, since it does create unaligned results, thus making it harder to read ? Doing so is (pretty much) asking for unaligned results, so it kinda make sense that's what you'd get... no?
Wouldn't it be easier to use a format that aligns everything, day, month and year as well ? Surely you have that on the list of available formats XY presents you...

Anyways, why not. About the additional space between dates & times, as long as the default/minimum size isn't changed (I don't want to lose pixels ), I'm fine with it, so why not.

Slightly off topic: is it me, but shouldn't XY, on the List of formats, use the current date to show the formats available ? Because we are now (over here) January 7th, 2009 and XY gets me example with the date of July 1st, 2009 -- Joincidence, or is there some mix up somewhere?

[j_c_hallgren]

Slightly off topic: is it me, but shouldn't XY, on the List of formats, use the current date to show the formats available ? Because we are now (over here) January 7th, 2009 and XY gets me example with the date of July 1st, 2009 -- Joincidence, or is there some mix up somewhere?

If we're talking about View>Date Col Fmt, mine shows the current date and time as substitutes for the model layouts...yours doesn't?

[jacky]

Slightly off topic: is it me, but shouldn't XY, on the List of formats, use the current date to show the formats available ? Because we are now (over here) January 7th, 2009 and XY gets me example with the date of July 1st, 2009 -- Joincidence, or is there some mix up somewhere?

If we're talking about View>Date Col Fmt, mine shows the current date and time as substitutes for the model layouts...yours doesn't?

Well... no. It seems XY is "confusing" somehow month & day, or something. It's no big deal since other than that it works fine, formats are used correctly and <date mm.dd> and the likes show the right thing too, of course, but all formats (on those menutiems only) have month & day "reserved", including the ones literally saying "July" -- Not sure why or how this is possible, but it's happening... I wonder what it'll say in a few days, on the 13th!

[TheQwerty]

Well... you can kind of cheat to make this better, but if your patterns allow for different widths it's only a small help.
Just apply the INI-tweak for custom date/time patterns, and put the value in quotes with leading or trailing whitespace. See below.

That's probably going to be the best you'll get. I don't think it's possible without rewriting the table control for Don to apply two different alignments or tab stops in a single cell which means he'd have to do string manipulation to pad the field out correctly and that's likely to be messy and maybe too time consuming.

Code: Select all

[ListDateFormats]
Version=1
; Tweak: edit the following as you need
3=dd/mm/yy
4=dd/mm/yyyy
5=mm/dd/yy
6=mm/dd/yyyy
7=dd-mmm-yy
8=dd-mmm-yyyy

[ListTimeFormats]
Version=1
; Tweak: edit the followig as you need
3=hh:nn am/pm
4=hh:nn AM/PM
5="          h:n:s"

[Mesh]

Well... you can kind of cheat to make this better, but if your patterns allow for different widths it's only a small help.
Just apply the INI-tweak for custom date/time patterns, and put the value in quotes with leading or trailing whitespace. See below.

I tried that, but it doesn't quite work. It works initially, but after XY is restarted a couple of times, it ends up stripping out the quotes first, followed by the padded spaces.

[Pagat]

Well... no. It seems XY is "confusing" somehow month & day, or something.

For me too. XY is showing "01.07.2009" in the menu but "07.01.2009" in the date column. Maybe the Windows regional settings come into play here and confuse XY? My windows "short date" format is set to "07.01.2009" whereas (i guess) the US people have a windows format like "07/01/2009" which works for XY? Just a guess...

[j_c_hallgren]

=whereas (i guess) the US people have a windows format like "07/01/2009" which work for XY?

Yes, we US folks use that format as our normal std, as in mm/dd/yyyy.

[admin]

All date columns should be right-justified, at least they are here, and this is what the code orders them to be.

[Mesh]

All date columns should be right-justified, at least they are here, and this is what the code orders them to be.

The point here was to have the date itself left-justified, and the time right-justified, and allow the width of the column control the spacing in between the two.

While not nearly as flexible or user-friendly, I would be okay using the INI tweak to manually create an option that allowed more space in between (I wasn't aware you could do this previously), but I can't do that while XY is stripping out double quotes and leading/trailing spaces.

[graham]

jc wrote:

Yes, we US folks use that format as our normal std, as in mm/dd/yyyy.

I remember that issue only to well in my early programming days in Vancouver - but it's illogical I said, but not to us they said!

[j_c_hallgren]

I remember that issue only to well in my early programming days in Vancouver - but it's illogical I said, but not to us they said!

I suspect it may tie into how it would be spoken, as I doubt one would normally say "Ok, todays date is 2008, Jan 7th" right? Or maybe y'all non-USA'ers do it so?

[PeterH]

Either we want it sortable, like 2009-01-13, or say (tried to translate) 13th (of) 1st of 2009 (that is 13. 1. 2009), or say 1st (of) January 2001, but never January 1st of 2009.

(As you see on the left: Germany )