Ticket #18 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

Staffbot date format

Reported by: Maverick Assigned to:
Priority: lowest Component: Bots - Other
Version: Latest version from repository Severity: trivial
Keywords: Cc:

Description

Rudy: "the date format on staffbot needs some consistency"

Attachments

Change History

04/22/07 17:01:50 changed by dugwyler

  • priority set to lowest.
  • severity changed from minor to trivial.

05/03/07 11:05:36 changed by dugwyler

Can Rudy provide an example as to how dates are inconsistent?

I know the warnings don't give the year, which I've offered to fix if I can have a sample of 5-10 warnings so that the text is parsed correct. Wonder what's up with the other dates.

05/03/07 11:54:58 changed by Maverick

Yea well I think it's inconsistent mainly because the dates show no year. I will ask him.

05/03/07 17:49:48 changed by Rudy

Warnings issued by the *warn command display the date on staffbot as, for example, 'Tue May 01'. Instead, the date format on staffbot when staffchat !warns are given display as 'yyyy-mm-dd', which is preferred as the former gives no indication of what year the warning was issued (which can be confusing given the length at which warnings remain in the DB). I suppose it is for this reason that when the warnings on a particular player are looked up, the records aren't always in chronological order as oldest to most recent. Take the player Primary for instance. There are at least three warnings from 2005 listed halfway down amongst warnings from 2006.

05/04/07 00:12:21 changed by Maverick

Aah alright. Thanks for the info, Rudy.

In would favour changing both date formats to a date format of dd mmmmmm yyyy (where the month is written out). For example; 1 May 2007 .
This date format is easily understood by everybody instead of having mm-dd-yyyy where most non-americans would have problems figuring out which is the month number and which is the day number.

… unless someone else has a better idea? :)

05/04/07 07:49:07 changed by dugwyler

The date standardization sounds good.

Unfortunately, the timeofwarning field is still never being used … what a poorly-planned system! The date is entirely in the text field and so it can't be reformatted in a consistent way without a little bit of text manipulation — else everything that we have presently will not correspond to the new system, if you understand what I'm saying. Even more annoyingly, RoboHelp and StaffBot format the text strings differently, so that two different parsing algorithms are going to be needed unless we can find one place of consistency a regex could snap up.

Again, though, in order to get started on this, all I need is for someone to do "!warning soandso" on someone that has a decent number of warnings (at least one of both *warn and staffchat !warn), and email or forum mail them to me. I'm not on staff so I can't do this. Please help!

05/04/07 14:34:04 changed by Maverick

I have send you a forum PM with the warnings of Primary which clearly show the date inconsistency.

05/06/07 10:05:54 changed by dugwyler

Thanks for the warning data. I have a regex that should match both formats and take out the date so that we can add it back in with a consistent format.

The clearest, most concise and also length-consistent date readout appears to me to be:

dd MMM yyyy

This will give dates such as "07 Jul 2006" and "24 Dec 1999".

The only bad part about this is that we can't include the time, because Java.sql.Date only stores the date info. So our only options, with the present legacy data, are:

1) An inconsistent date format; or,

2) No time information

Personally I would prefer no time information, but from what I remember, mods sometimes use time information to determine if a player has had a warning for something in the past 24 hours? Maybe not. Anyway, I'm guessing that consistency is most important but let me know if staff needs the time info and this project should be abandoned.

05/06/07 10:44:39 changed by Maverick

Hmm I would also vote for no time information since it's quite irrelevant for day-to-day operation. The time is stored in the database, right? Then it should be just another trick to get it out. (?)

05/06/07 10:58:31 changed by dugwyler

For some reason java.sql.Date sets all time information to 0, I think because of lack of time zone info.

05/06/07 13:59:43 changed by Maverick

No, it does that by definition:

To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated.


However it seems it's still possible to get the time by using java.sql.Timestamp:

public class DateLabel {
  public static void main(String[] args) {
    java.util.Date today = new java.util.Date();
    System.out.println(new java.sql.Timestamp(today.getTime()));

  }
}

Found this by doing a google search.

05/06/07 14:02:59 changed by Maverick

Hmmm that probably doesn't work since the java.sql.Date has already reset the time to 0 (yea, the code example uses java.util.Date).
However can't you just get a java.sql.Timestamp from the same column instead of the java.sql.Date ?

05/06/07 14:30:59 changed by dugwyler

Not 100% certain on that. java.sql.TimeStamp extends java.util.Date rather than java.sql.Date version. However, they each at least implement the Comparable interface in reference to one another…

The only thing that really leads me to think we might not be able to get the time info is that all of the time-related getter methods in java.sql.Date have this reason for being deprecated:

"This method is deprecated and should not be used because SQL Date values do not have a time component."

This might mean that they're just not getting that info and that it can be taken out with something like Timestamp. But, java.sql.Date is the data type that a date/timestamp is placed into before being inserted in the timeofwarning field (yeah, great naming convention, heh). This leads me to believe that the info will not be accessible … that at best, what we will get is midnight in the particular time zone in which the core is running.

Also, I do have the code done whenever a decision's made. Would be cool to have the time in if there's a way to do it, but it sounds like it's not entirely necessary. For example, is it ever used? (Just trying out the new Wiki tools, haha.) If time info is never needed by staff, it would probably even be good not to include it, regardless of the availability. Would keep the screen spam down.

05/07/07 22:50:18 changed by Rudy

I'll speak for everyone when I say it's preferred there be no time information if given those two options. Precise time is rarely needed and can still be looked up via Arrogant's log functions, where required.

05/25/07 06:26:46 changed by dugwyler

  • status changed from new to closed.
  • resolution set to fixed.

This should be in. Reopen if needed.


Add/Change #18 (Staffbot date format)




Change Properties
Action