Skip to main content

Add Date, Time and TimeStamp classes to java.lang

8 replies [Last post]
Joined: 2003-06-10

Add these classes:

Deprecate the following classes:

These new classes must be immutable. All three will have three common types of constructors as following:
- A no-arg constructor to represent the current date/time/timestamp when the object is created.
- A constructor that takes one ‘long’ argument, milliseconds since January 1, 1970, 00:00:00 GMT.
- A constructor that takes two arguments; a String, the string representation of the date/time/timestamp value, and a format object, representing the format of the value.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-01-04

I think the best place for these new classes would be in a package [b]java.util.time[/b]. That way they get their own self-contained package and can easily accommodate a larger number of classes. To do a time API right would probably require other classes beyond the basic Date and Time classes (e.g., TimeZone, DateRange, etc.).

I also agree about deprecating java.util.Date and java.util.Calendar. The Date class wasn't properly designed, and then the Calendar class was added to sort of function as a Date class, even though its name doesn't really say what it does. I don't feel as strongly about the classes in java.sql.

The new API should make it much easier to create and manipulate dates and times.

Joined: 2004-10-07

This is an excellent suggestion, although I agree with previous posters that "java.lang" is probably not the right place.

I would add that there are a lot of other time-related definitions that would be of value to standardize; e.g. "Duration".

Joined: 2003-12-02

And what's the rationelle?

The existing API works quite well enough thank you.

Or if you want to change the date API why not define a date as a primitive to get a good laugh.

Joined: 2003-06-10

> And what's the rationelle?

So that we don't have to live with those badly designed classes (with most methods already deprecated) for ever. Have you looked at the api of those 4 classes lately ? I guess it looks alright to you.. eh ?
Also note the sentence "These new classes must be immutable".

> The existing API works quite well enough thank you.

May be for you. I don't think most people share your view given the number of negative comments in other forums about the current classes.

> Or if you want to change the date API why not define
> a date as a primitive to get a good laugh.

I did not even think of those as primitives.

Joined: 2004-10-14

Not to java.lang (name space clashes), but add a java.datetime (or package and put a sensible Date/Time/Calendar API there.


Joined: 2003-06-10

The reason I chose java.lang is two-fold:
- These are frequently used "data type" classes
- allows to import automatically just like String.

There shouldn't be any name-space problem. If you don't import anything it will be the new one from java.lang, if you already have import java.util.Date/java.sql.Date you are not using the new java.lang.Date. Isn't that correct ?

Joined: 2003-11-16


Also, an new Calendar API that is 1) easy to use, 2) uses Enums instead of ints.

Joined: 2004-09-17

What about Calendar?