Versions Compared

Old Version 3

changes.mady.by.user Unknown User (adrianc@hlmksw.com)

Saved on

compared with

New Version Current

changes.mady.by.user Jacques Le Roux

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Adds 3 TImeZone rules

...

  1. Understand the related Java classes java.util.Datejava.util.Localejava.util.TimeZonejava.util.Calendar and org.ofbiz.base.util.UtilDateTime
  2. Avoid making assumptions
  3. Never use millisecond arithmetic

Also long ago Adrian suggested this 3 rules/use-cases which make much sense and helps to understand, more could be added...

  1. Automatic server processes like the Job Scheduler should use the server's timezone.
  2. Customer-facing processes should use a product store's timezone. Example: "Your order will be shipped by 4:30 PM PST today."
  3. Calendar applications (anything work effort related) should use the user-selected timezone.

 

The java.util.* Classes

 

The java.util.Date class, and its subclass java.sql.Timestamp should be thought of as a constant. It is an immutable moment of time occurring in GMT. (The Date class has setXxxx methods, but they are all deprecated.) You cannot change a Date's time zone - it is, and always will be, referenced to GMT.

...

Knowing that the Date class wraps a millisecond value makes it tempting to use millisecond arithmetic to perform date/time calculations. That approach will always fail - because it doesn't take into consideration different calendar systems, time zones, etc. OFBiz developers should never use millisecond arithmetic.