Help requested from people running from source

[chaley]

I just made some changes to handling of dates in the GUI that might introduce "regressions" (OK, bugs). Kovid has merged the changes into 'trunk', and I would very much appreciate it if people who run from source could try it out before this week's release.

I have converted all dates in the GUI to date_time, which means that all date fields now contain a time as well. If the format permits showing times, then you can set and set the time. For the standard columns, the formats are set using tweaks. For custom date columns, the format is set by editing the column setup.

There are behavior changes. The biggest is that when editing you will see only the fields that the format specifies. For example, if your pubdate format is "yyyy", when editing you will see only the year. Before, you would see the month and the year. If you change your timestamp format to "dd MMM yyy hh:mm:ss", then you will see and can change both the date and the time. You could also do this for pubdate, but I am not sure why you would want to.

Another change: the tooltip for a cell will show the date + time, regardless of the format.

The tweaks for the three standard date fields are gui_last_modified_display_format, gui_pubdate_display_format, and gui_timestamp_display_format.

The time format options are:

• h : the hours without a leading 0 (0 to 11 or 0 to 23, depending on am/pm)
• hh : the hours with a leading 0 (00 to 11 or 00 to 23, depending on am/pm) m : the minutes without a leading 0 (0 to 59)
• mm : the minutes with a leading 0 (00 to 59)
• s : the seconds without a leading 0 (0 to 59)
• ss : the seconds with a leading 0 (00 to 59)
• ap : use a 12-hour clock instead of a 24-hour clock, with "ap" replaced by the localized string for am or pm
• AP : use a 12-hour clock instead of a 24-hour clock, with "AP" replaced by the localized string for AM or PM

Example: the values of the tweaks for testing are

gui_last_modified_display_format = 'yyyy/MM/dd hh:mm:ss'
gui_pubdate_display_format = 'yyyy'
gui_timestamp_display_format = 'dd MMM yyyy hh:mm'

For this week, please post bugs/questions here. Once the changes are released and stable, bug reports will become preferred.

[capnm]

Hmmm....
How does this affect my question here ?

Specifically -- will a composite column such as {date} now sort on the date-time underlying "Date" instead of the visible mm/dd/yy?

Will pubdate sort on the visible "yyyy" or the underlying, possibly misleading date-time?

Would it make sense to have a tweak regarding sort behavior -- sort on display vs sort on underlying date-time?

(It's when you're doing nested sorts that it matters).


Edit:
I guess my preferred behavior would be to have dates sort on what is displayed, but as though they were dates, not just text.

[chaley]

Originally Posted by capnm

Specifically -- will a composite column such as {date} now sort on the date-time underlying "Date" instead of the visible mm/dd/yy?

No. It will sort on the data in the column, just as before. Of course, the data in the column depends on what the format string for the underlying date is.

Will pubdate sort on the visible "yyyy" or the underlying, possibly misleading date-time?

No change in behavior -- it sorts on the date-time.

Would it make sense to have a tweak regarding sort behavior -- sort on display vs sort on underlying date-time?

Make sense, but I would like to see the performance hit first. Also, you don't want to sort on the displayed value, because that would make things like Mar 22, 2001 come out after Apr 1, 2001.

[capnm]

Edit: This became a moot cross post -- chaley responded here

Many thanks chaley!

[chaley]

I understand what you want to do, and I think I answered the question on your other post. I am not totally convinced that the behavior you want is correct, but I am willing to go along with it. Reason for doubt: looking at a subset of the information does not always mean that it should sort that way. For example, consider a net-worth column. Should it sort by pennies because that is what I am looking at, or should it respect the 'real' net worth? Arguments exist on both sides.

Also, sorting the {date} column does sort as a date-time. The parts that are not shown are set to some default, which depending on the template may cause the sort to behave as you want.

As I said, I am willing to go with the 'sort by what I see' position if Kovid is. Repeating that other post here for completeness: I have an implementation that sorts dates as displayed. The performance penalty is not huge. For a 20,000 book library, the time to sort by a date column went from approximately 1/2 second to 1 second, or some 500 microseconds per book. This is consistent with my mark 1 eyeball estimate of the cost of trimming the date.

[...]

One note: the sort will respect strange display templates and do something. If your display template is, for example yyyy/ss, then the month, day, hour, and minute will be filled in with a constant. The results could easily not be what you expect. Continuing the example, 2011/10/25 19:08:10 and 2011/01/19 10:10:10 will sort as equal because the years (2011) and the seconds (10) match.

[capnm]

Originally Posted by chaley

... looking at a subset of the information does not always mean that it should sort that way.

Agreed.

And if I were sorting only on a date column, I'd probably prefer as granular a sort as possible, minimizing 'randomness' of the result.

That's what I like about your implementation -- I can have my cake and eat it too!

If I want a date sorted to the second, I just display it so. (Actually what you've implemented is even better, I determine the sort granularity with the display format tweak, but I can still refine the appearance by adjusting the display column width -- so I can sort to the second while displaying only the day).

If I want a different date less granular to facilitate nested sorts I display (format tweak) it accordingly.

If I'm willing to take the hit of restarting calibre, I can even switch back and forth! (Though I can't really imagine wanting to do that).

I like it!

[capnm]

Okay, chaley, I'm feeling a little guilty here, since there's no evidence of anyone, including me, testing the source ...

Now it's obviously too late this time round, but am I correct that only released source is available as a tarball? And that to get the unreleased 'trunk' I'd have to install bazaar (which I'm too lazy to do, at least yet)?

Thanks ...

[DoctorOhh]

Originally Posted by capnm

Now it's obviously too late this time round, but am I correct that only released source is available as a tarball?

I'm guessing no.

Originally Posted by capnm

And that to get the unreleased 'trunk' I'd have to install bazaar (which I'm too lazy to do, at least yet)?

The instructions for setting up the development environment is here.

[kovidgoyal]

Yes, you need bzr to get unreleased source.