Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The documentation of the Java TimeZone and derived SimpleTimeZone classes state that...</p> <blockquote> <p>The class holds an offset from GMT, called raw offset, and start and end rules for a daylight saving time schedule. Since it only holds single values for each, it cannot handle historical changes in the offset from GMT and the daylight saving schedule, except that the setStartYear method can specify the year when the daylight saving time schedule starts in effect.</p> </blockquote> <p>This means that if your application does not rely on historical dates/times, you won't have issues if the TimeZone object you're using at the time that these objects are generated are up to date.</p> <p>However...</p> <p>If your application contains any sort of database of historical dates/times, then when a new Time Zone rule goes into effect, you application will erroneously interpret your historical information and display incorrect results since the TimeZone object it will be using is not the same as the TimeZone object that was used at the time your historical data was generated.</p> <p>If it is important to you to maintain historically accurate dates/times (such as, for example, billing records to government agencies that have very sharply defined parameters for billing eligibility) then you'll need to store not only your historical date/time information in your database, but information that can be used to recreate the time zone rules that were in effect at that time as well. There are a few possible solutions.</p> <p>The Java SimpleTimeZone class has a constructor that will allow you to create a TimeZone object with a single set of time zone and daylight savings rules:</p> <blockquote> <p>SimpleTimeZone(int rawOffset, String ID, int startMonth, int startDay, int startDayOfWeek, int startTime, int endMonth, int endDay, int endDayOfWeek, int endTime, int dstSavings)</p> <p>Constructs a SimpleTimeZone with the given base time zone offset from GMT, time zone ID, and rules for starting and ending the daylight time.</p> </blockquote> <p>So, just make sure you store all the date/time information in your database as UTC timestamps. I like to store timestamps in databases as "Modified Julian Day Numbers" which are able to store calendar dates and times to millisecond precision in a double. Modified Julian Days numbers are always defined in UTC. Whatever though, as long as your info is in UTC, you're standard.</p> <p>Then, you can create a table of all the arguments needed to create the SimpleTimeZone objects ever used in your database, or you can simply persist all the objects used by your database with the object persistence API of your liking. With a foreign key that indicates the time zone rules used for the relevant data, you can assure that your database application can report historically accurate local times.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload