Java missing 28 seconds

Question

I'm trying to extract a table from a database and reloading it in another type of database. The problem is that with my local settings the date 1 july 1937 poses a problem of gettng the timestamp when its 00:00:00. In the netherlands they changed meridians in 1937 causing the first 28 seconds of 1st of july 1937 not existing.

When i'm reading the date into a calendar to reformat the output, the time changes to either 28 seconds before the date; june 30th 23:59:32 or july 1st 00:00:28 (depending on driver) Anyone knows a workaround around this problem?

http://themagicofscience.blogspot.com/2010/08/java-puzzler-1-july-1937.html

Answer 1

Configure your Calendar to use a different Locale.

Calendars translate the encoded time into the local time. Those 20+ seconds just don't exist with different display formats in that Locale, so if you insist on keeping that Locale, and you insist on displaying dates with seconds set so, then you need to take it up with the Dutch government in 1937; however, if you change the display formatting to that of a different Locale, you will discover that the actual value of the underlying time data structure wasn't changed, it will resolve to different times in locales that have different seconds values to display.

The only caveats is that should you manipulate the time between reading it and storing it, then you might inadvertently create a new Time or Calendar object, which would set or reset its underlying data structures based on a translation of the Locale formatted time into the underlying data representation.

This is why it is best to handle bulk date and time handling in UTC, without daylight savings. Even though the times don't match up to the local times (and are harder to read for people in different time zones), every second of UTC exists, so simple +5 second changes can quickly be verified by a simple formatting of the impacted time.

The only caveat with this sort of handling is that later, you must always translate UTC time back to local time for display. Depending on the education of your audience, some of the Dutch might be shocked to find that their government didn't allow such seconds to exist and might demand that they are shown despite the rulings that such seconds are not part of the Dutch calendar.

Just wait until you discover the missing days back in 1582.

Answer 2

In Java, a date is stored internally in a time-zone independent way. (It's stored as the number of milliseconds since -- I forget the starting date, was it Jan 1, 1970 GMT?) When you output a date, THEN it has to take the time zone into account. But any internal manipulations shouldn't matter. You didn't say what database engine you're using so I don't know how it stores dates. I'm mostly working with Postgres these days, which stores all dates in GMT and converts to and from the appropriate time zone at input and output time.

So if you just set your time zone to GMT, then any changes for moving time zone boundaries, daylight savings time, etc should be irrelevant.