Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[vagskal]

I have been adding the exact release date, not just the release year, to my music albums and have noticed a couple of things:

1. Why is there no sanity check as regards the Date field? If I misspell the date I can without warning end up with setting the date to 2320 something. A warning would be in order if the date entered has not occurred yet (or if the date is before say 1920, but I have not seen that with my misspellings). Likewise a warning could be issued if the entered value is not a valid date according to the locale (omitting the "-" part in ISO countries, i.e. 199506, can lead to strange dates).

2. If I enter just the year and month (1995-02) MC sets the full date to the first of the month (1995-02-01). Why is it not possible to omit the day part to distinguish this case from when an album is actually released on the first day of a month?

3. Why is the month and day value set to 01, i.e. the first day of January, when there is only a year value, and and the day value set to the first day of the month when there is a month but no day value? This looks strange when having a Month or Day pane/column. Although the Month and/or Day is unassigned by me (and not displayed in the MC Date field) those albums are not sorted in the Unassigned category but in the January/first day category. And it looks like January and the first day of a month is by far the most popular time to release an album.

4. Is there a way to sort albums without a month value last when sorting by date, like the sort empty values last option? And the same for albums with a month but no day value.

5. Is there any way to distinguish the files where I have actually entered 01 as the month or day from the files where MC has done that automatically? If not, and had I realised that MC automatically fills in values, I would have used a non date type field to enter my values (and imported that field to the Date field) to avoid having to look up again the albums actually released sometimes in January or the first of a month. 

I have already read some threads recommended by Alex regarding date handling and the Excel style date format. Is it this format that requires a fictive full date for values missing the month or day part? (Sorry if I missed one of all the threads on this that gives the answer.)

(The earliest track I have is originally released in 1899 and I just wondered how the Excel format would handle that; it is not currently a problem for me, though, since I do not use a date type field for original release date and that track is of course on a compilation released much later.)

[MrC]

A quick response, primary re: #2 which might help clarify some things.

A date field is stored internally in MC as a single floating point number.  When you enter a date, MC converts your string of characters.  When it displays a date, it uses the default date format, or the formatting that arises from whatever expression used to present the date the way you want.

Since MC must convert a string of characters into a single floating point, it must assume some value for missing portions, such as day.  Otherwise, there would be no way to apply a mathematical conversion, as one of the variables in the equation would be undetermined (and that would represent a range of date values).

So it sounds like you're asking how can MC know that you never entered a day value in a date field, and hence display either 2008-02 or 2008-02-20, according to what you had entered.  I think if it is a date field, answer is, it can't do that.  For this, a general string field would be necessary.

[vagskal]

Thanks for the reply!

Since MC must convert a string of characters into a single floating point, it must assume some value for missing portions, such as day.  Otherwise, there would be no way to apply a mathematical conversion, as one of the variables in the equation would be undetermined (and that would represent a range of date values).

So it sounds like you're asking how can MC know that you never entered a day value in a date field, and hence display either 2008-02 or 2008-02-20, according to what you had entered.  I think if it is a date field, answer is, it can't do that.  For this, a general string field would be necessary.

I read this thread where Matt explains how MC adds fractions of seconds to differentiate between a blanket year, 2006, and a full date, 2006-01-01. http://yabb.jriver.com/interact/index.php?topic=50750.msg346804#msg346804

It sounds like that would work also when only the day part is missing.

The problem for me is that, after entering many date values, I cannot figure out how to use this distinction.

[MrC]

Thanks for the reference.  I now recall reading it, but maybe I've misinterpreted Matt's description.  His comments seem to indicate that fractions of seconds are added for *time* fields (i.e. fields that include time, as well as date), not simpler date fields.  Time is stored as <int>.<frac>, where date only fields are <int> only.

Alex B indicates only the Date Imported, Date Modified and Date Created fields are Time values:

http://yabb.jriver.com/interact/index.php?topic=43983.msg301174#msg301174

This makes sense to me, as I can't imagine anyone needing, for example, a Release Date with a time value.  And the Date {Imported, Modified, Created} fields track the equivalent typical file time stamps.

[vagskal]

I do hope it is not so. That would surprise me. Precisely the dedicated Date field not being able to retain, or restore, the entered incomplete date value, but all other date handling (and string) fields are.

(To be able to distinguish incomplete values, the fractions would be useful/necessary in a release date field the way Matt explained.)