Java is missing 28 seconds

I am trying to retrieve a table from a database and reload it into another type of database. The problem is that with my local settings, the date of July 1, 1937 creates a problem with the time stamp when it is 00:00:00. In the Netherlands, they changed the meridians in 1937, as a result of which the first 28 seconds of July 1, 1937 did not exist.

When I read the date on the calendar to reformat the output, the time changes 28 seconds before the date; June 30 23:59:32 or July 1 00:00:28 (depending on the driver) Does anyone know a workaround for this problem?

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

+8
java calendar
source share
4 answers

Configure Calendar to use a different Locale .

Calendar translate the encoded time to local time. These 20+ seconds simply do not exist with different display formats in this Locale , so if you insist on keeping this Locale , and insist on displaying the dates with the set seconds, then you need to take it with you the Dutch government in 1937; however, if you change the display formatting to another Locale , you will find that the actual value of the base time data structure has not been changed, it will be resolved to different times in locales that have different seconds for the display.

The only caveat is that you have to manipulate the time between reading and storage, then you can inadvertently create a new Time or Calendar object that would set or reset its basic data structures based on translating the formatted Locale time into a basic data representation.

This is why it is best to handle date and time processing in UTC, without daylight saving time. Despite the fact that the time does not correspond to local times (and it is harder to read for people in different time zones), every second of UTC exists, so simple +5 second changes can be quickly checked by simply formatting the impact of time.

The only caveat associated with this type of processing is that later on you should always translate UTC time back to local time for display. Depending on the education of your audience, some of the Dutch may be shocked to find that their government has not allowed such seconds to exist and may require them to be shown, even though such seconds are not part of the Dutch calendar.

Wait until you find the missing days in 1582.

+3
source share

In Java, the date is stored internally regardless of the time zone. (It is stored as the number of milliseconds since then - I forgot the start date, was it January 1, 1970?) When you set the date, THEN it must take the time zone into account. But any internal manipulations should not matter. You did not say which database engine you are using, so I do not know how it stores dates. I mainly work with Postgres these days, where all dates are stored in GMT and converted to the corresponding time zone and from the corresponding time at the entrance and exit.

So, if you just set the time zone to GMT, then any changes to move the borders of time zones, daylight saving time, etc. should be irrelevant.

+1
source share

The simplest is likely to be a simple check for these specific times and, accordingly, changing the date.

0
source share

Try it and select dates in GMT or UTC, then load them that way. You will then use the details of the new system for the locale, not the original system.

0
source share

All Articles