1

I want to be able to change the base millisecond reference from 1970 to 2008 in Java so that I can save space in the database and unique Ids.

Preferably with Joda-Time.

The upcoming jsr-310 in the supposed Java 7 release implements it.

In the The Discrete Timeline section of this link it states that the counting of milliseconds has changed from 1970 to 2008

http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html

The only other option I can see is to mathematically implement it every time I need to look up a record.

E.g. 

DateTime dt = new DateTime();  
long now = dt.getMillis();

DateTime dt2 = new DateTime(2008, 1, 1, 0, 0, 0, 0);  
long then = dt2.getMillis();

long smallerDate = now - then;

Smaller date will be stored in the DB

-- Edit --

So I misread the JSR-310, and it's not possible.

There are better ways to save space and then a headache of processing thousands of request to calculate longs.

I wanted to record longs as dates because I'll never know where I will move the DB to, perhaps MySQL => Oracle.

So I didn't want timestamps, I just wanted BigInts.

amaidment
  • 6,942
  • 5
  • 52
  • 88
Daxon
  • 1,397
  • 2
  • 21
  • 38
  • 4
    How is this supposed to save space in the DB? Sure, that *text representation* of the `long` value would be slightly shorter, but if you declare the column to be of type `bigint` (or similar, as you have to in order to store the value), it take the same size regardless of the beginning of the epoch. – Dirk Sep 24 '09 at 13:52
  • surely you mean `new DateTime(2008, 1, 1, /*12*/0, 0, 0, 0);` Or does Joda *actually* start measuring time from noon? – Kip Sep 24 '09 at 13:54
  • The linked article was also misread. The 2008 date was simply given as an example as to nanosecond resolution, but it will still return timestamps from 1970. I'd look for other ways of saving space. – Nick Sep 24 '09 at 14:02
  • @Kip, Sorry yes it should have been "0" instead of noon (i'll edit) @Nick, Sorry again, ill be more careful. – Daxon Sep 24 '09 at 14:36

1 Answers1

8

No you can't, and it would be a bad idea if you could. Every timestamp in your database is going to use the same space, regardless of how big the number is. (Assuming you are storing the number as a number and not as a string or something.)

Now, if you really want this, you'll have to write it yourself. I.e. subtract the time from your timestamps before putting them into the database, and add the time to the timestamps when you get them back out. But this is asking for maintenance problems. (In fact, using timestamps instead of the database's native DATETIME datatype is asking for problems.)

Kip
  • 107,154
  • 87
  • 232
  • 265
  • Actually, integers can be compressed using 7-bit encoding, so that values 0 <= x <= (2^7-1) use one byte, (2^7) <= x <= (2^14-1) uses two bytes, etc, which is useful when CPU is cheaper than I/O and you expect most numbers won't be huge. – gustafc Sep 24 '09 at 15:18
  • 1
    Which, btw, does not detract from your main point about the wiseness of using the database's DATETIME. But, if you were to do something like this, I'd start by looking for some setting in the database rather than one in the application platform. – gustafc Sep 24 '09 at 15:21