Indefinate dates [DONE]

old granted and denied feature requests

Moderator: AniDB

Locked
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Indefinate dates [DONE]

Post by Rar »

The sucess of this request will probably rely entirely on the data type exp is using for dates of things. Basically, it's common to be able to find out a year, or month for a particular air/release date, but not an exact day. At the moment there are two possibilites is this situation, either leave the date undefined and lose the information you do have (preventing voting in the case of animes as well), or put in a fake date (generally 1.1.X or 1.X.X). The problem is, as the fake date is actually a real one, this is bound to cause confusion over what is real information, and what is placeholder.
So, if the format allows it, I'd like part-undefined dates, eg 0.0.1988 or 0.11.1997 - this way it is clear that the date is at some point within a period, but unknown. It would also mean perm. voting for obviously finished animes could happen again.
Secondly, there is duplicate data in the anime entries, as there is both a 'year' start/end field and a 'date' start/end field. Having part-undefined dates would mean the redundancy could be removed.

Rar
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

Post by DonGato »

/me points to the tracker. :P
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

Post by exp »

the start and end dates are stored as integer values (seconds since 01.01.1970).
such a placeholder wouldn't be that easy.
on the other hand, we're only using the time 00:00 atm, so we could use other times as special markers.
this is somewhat ugly though.

BYe!
EXP
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

exp wrote:on the other hand, we're only using the time 00:00 atm
Actually you are using 7am, only perl hides that from you.
Anyway, that's not to main reason for posting this. You also use 8am, this due to daylights saving. So if you do this you have to fix time handling to ignore the current timezone.

(Actually I only think it is 7am and 8am, been a month since I fiddled with the dates last.)
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

What about the poor 60s anime!

The main reason for this as a feature is that even the companies who made the things can be horribly vauge on the dates for older anime. If some kind of date format accomidated this, think it'd be useful.

Rar
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

Right. Reasons current system is bad:
-Two date fields, which may contain conflicting information.
-Inability to store anything other than exact values.
-Redundancy. You're storing a time of day when you don't need to.
-I presume you're using a signed integer for seconds, otherwise storing dates before 1970 wouldn't be possible.
-The number of seconds since 1970 is not actually a value you can rely on. Sure, this is a purely academic issue, but it's the kinda thing that annoys me.

Hack solution:
Use current system
Set all time-of-days to 00:00
Use 00:01 to indicate year *only* is know
Use 01:00 to indicate year and month *only* are know
Junk 'Release Year' field, if no information is in start and end date, add release years as 00:01 values
Ensure future dates are input with 00:00 times as default
Add interface for only adding year / year+month as an option

Advantages: Only means running a few queries on the db and updating some of the interface.
Disadvantages: Not very elegant.

Alternatives?

Rar
egg
Posts: 769
Joined: Tue Nov 11, 2003 7:17 am

Post by egg »

For the record, I like this solution better than How to determine if an anime has started/finished for voting.
kidan
Posts: 319
Joined: Thu Feb 13, 2003 9:13 pm
Location: .DE

Post by kidan »

exp wrote:the start and end dates are stored as integer values (seconds since 01.01.1970).
Those would not happen to be signed integers? Then we could use the negative value to mark an estimate.
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

Post by exp »

kidan wrote:
exp wrote:the start and end dates are stored as integer values (seconds since 01.01.1970).
Those would not happen to be signed integers? Then we could use the negative value to mark an estimate.
they're signed ints and the negative values are used for dates < 1970.
(the ints are the values as the time() and localtime() functions in perl provide/require)

BYe!
EXP
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

Rar wrote:Set all time-of-days to 00:00
Use 00:01 to indicate year *only* is know
Use 01:00 to indicate year and month *only* are know
This won't work as the current anidb code doesn't understand daylight time saving. It'll mean half the year it'll work, half the year it won't.
(Actually it'll be bugged all year round if you think about it.)
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

Rar wrote:Ensure future dates are input with 00:00 times as default
That's one of the things on the needs-to-be-fixed list.

Rar
Elias
Posts: 242
Joined: Tue Feb 17, 2004 4:55 pm

Post by Elias »

PetriW wrote:This won't work as the current anidb code doesn't understand daylight time saving. It'll mean half the year it'll work, half the year it won't.
Then maybe different way:
Use year-01-01 04:00 to indicate year *only* is know
Use year-month-01 08:00 to indicate year and month *only* are know
Use year-month-day 12:00 when full date is known.
Then if hour would be checked between those values (if hour<10, only year and month are know, if hour<6 only only year is know, other values: year,month and day are known) there should not be problem with daylight saving time (one hour can be added/subbed to date without change of meaning).
Also coding like this preserves correct sorting by date (placing dates with not all defined before others), in result sort will be like this:
2005-??-??
2005-01-??
2005-01-01
2005-01-02
...
2005-01-31
2005-02-??
2005-02-01
...

Maybe for finishing dates can be used additional other coding (for sorting purpose only, is there any sorting by air finishinig date?):
Use year-month-last_day_of_month 16:00 to indicate year and month *only* are know
Use year-12-31 20:00 to indicate year *only* is know.
Then sorting would result this:
2005-11-30
2005-11-??
2005-12-01
...
2005-12-31
2005-12-??
2005-??-??
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

Two obvious indefinates I should have mentioned as well - anidb currently only has one of these. Indefinate past, and indefinate future. At the moment has the latter, and the main problem with a lot of animes is they have an indefinate... which is the future... so can't be voted on. Even when it's obviously the past.

I know that implementing all this will be a *bit* of a pain, first changing dates to UTC, then adding funny time-of-day handling, then updating the interface, but I really think it's worthwhile...

Rar
egg
Posts: 769
Joined: Tue Nov 11, 2003 7:17 am

Post by egg »

Rar wrote:Indefi... I should tracker it I guess.

Rar
I keep waiting for you to do it so I can add my 2 cents...
Locked