02:41 pm - sparkymark - TimeZone On Windows there is an "Automatically adjust clock for daylight saving changes" tickbox on the clock. At this time of year unticking it takes time back an hour in my part of the world (UK). This change in the system time is respected by a Java program that starts after the box is unticked, but if the box is de-ticked (or re-ticked) after the program starts then that change is not respected by DateTime.fromCalendar( Calendar.getInstance() )I have seen rants on how Windows should store its times in UTC format for Java's benefit, but is there a workaround to force the TimeZone object used by the Calendar to reinitialise? I have used reflection to get at the private static method of TimeZone that sets its defaultTimeZone field, but that makes a call to a mysterious TimeZone implementation sun.util.calendar.ZoneInfo that I think is failing to respect the change in the daylight savings flag.
sparkymark - TimeZone On Windows there is an "Automatically adjust clock for daylight saving changes" tickbox on the clock. At this time of year unticking it takes time back an hour in my part of the world (UK). This change in the system time is respected by a Java program that starts after the box is unticked, but if the box is de-ticked (or re-ticked) after the program starts then that change is not respected by DateTime.fromCalendar( Calendar.getInstance() )I have seen rants on how Windows should store its times in UTC format for Java's benefit, but is there a workaround to force the TimeZone object used by the Calendar to reinitialise? I have used reflection to get at the private static method of TimeZone that sets its defaultTimeZone field, but that makes a call to a mysterious TimeZone implementation sun.util.calendar.ZoneInfo that I think is failing to respect the change in the daylight savings flag.