[cirrus3]

Why are you using the Calendar API in Java? It is full of issues like this.

[tisdadd]

I never really understood why not simply use milliseconds since the epoch and keep track of a time zone separately if needed... This allows fairly easy conversion to most native systems i have worked with, easy sorting and diff operations as well as final display control. Also don't have a need to be thinking about daylight savings then, or do other conversions for say timesheets.

[patrickthebold]

It depends on what you need to do. If you just need to say when something happened (e.g. some log event) then milliseconds since the epoch is fine. If want a user to schedule a reoccurring meeting at 8am on the first Thursday of every month, you can also keep a set of timestamps as milliseconds since the epoch, but you are going to need to do some work to figure out the right numbers correctly.

[klysm]

Timezone rules change. If you want to be fully robust, you need to store the intent of the time

[tsss]

Because a calendar date and a point in time are entirely different things.

[QuercusMax]

I didn't write the code originally; this was like 15 years ago. If the API still exists people will misuse it.

[thebruce87m]

I don’t know anything about calendar pitfalls or Java, but I would have loved to see a better alternative suggested here.