We Keep Coding

Joda Time Returns Correct Date, but Java Time Doesn't

I support a large enterprise app and we have two classes that use LocalDate.now to get a timestamp, one uses joda time, one uses Java time. Typically we restart every night, but earlier this week we weren't able to. On the second day of the application running, the class using joda time returned the correct date (20200505) but the class using Java time returned the date the application was turned on (20200504).
Both classes make a new call to LocalDate.now in the method each time it's called.
Java time:
String date = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
//Use timestamp
Joda time:
LocalDate date = LocalDate.now();
String format1 = date.toString("MM/dd/yyyy");
//Use date
Why does the Java 8 implementation of LocalDate.now return the wrong date after the server date has changed without an application restart?

The class with the issue is an enum, and it turns out in another call the value of a field in the enum was being changed and saved, so when the app was doing the timestamp replacement, the placeholder was no longer in the enum after the first call. Who knows why. Fixing this fixed the issue, no problem with Java time.

The local date depends on the default time zone, as there is no global date.
I assume that the time zone in your server is off, and this still returns yesterday's date for a few hours after midnight. This is a quite common configuration error when configuring the server to run in UTC whilst the actual timezone is more on the eastern side.
https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getDefault--
If the cached default TimeZone is available, its clone is returned.
Otherwise, the method takes the following steps to determine the
default time zone.
Use the user.timezone property value as the default time zone ID if it's available.
Detect the platform time zone ID. The source of the platform time zone and ID mapping may vary with implementation.
Use GMT as the last resort if the given or detected time zone ID is unknown.
You can easily verify that by getting the LocalDate.now() after changing the default time zone:
TimeZone defaultTimeZone = TimeZone.getDefault();
try {
Arrays.stream(TimeZone.getAvailableIDs())
.map(TimeZone::getTimeZone)
.forEach(timeZone -> {
TimeZone.setDefault(timeZone);
System.out.printf("%s in %s (%s)\n",
LocalDate.now(), timeZone.getID(), timeZone.getDisplayName());
});
} finally {
TimeZone.setDefault(defaultTimeZone);
}
So the question is: which time zone does your server use?

DateTime to java.sql.timestamp conversion is adding +1 hour

I am calling my rest api with following url localhost:8080/api/2016-05-30T10:30:00-05:00/3
The api receives date as String and then convert it into jodatime datetime object like dateTime = DateTime.parse(date); ... debugging this code shows that its resulting in expected value.
However, when i am converting this date to java.sql.timestamp like Timestamp ts = new Timestamp(dateTime.getMillis()); ... the resulting time is 2016-05-30 11:30:00.0 ... why is it adding +1 hour to the time and whats the proper way to convert ?
SOME BACKGROUND
I have saved the time as timestamp in sql table. with timezone (as a string +4:00 or -5:00 for example) in a separate column.
I would receive an ISO8601 time in my url path parameter and based on that I have to fetch the record from db. For that, I will be using two comparison. 1 to match the time and 2 to match the timezone.

The ISO 8601 states that
... the time in New York in winter is UTC−05:00
So it seems daylight saving time is not included in the date string, which means what you get is the correct time, as per the defined timezone (-05:00). New York summer time should be -04:00, as DST is not part of ISO 8601.
You could add an extra DST column in your database or add it as a parameter, or go through the process of checking whether you are in DST, which varies country to country (e.g. Qatar does not uses it) and year by year (e.g Russia has abandoned DST a few years ago), so it's not a viable option...
EDIT:
Another option would be for you to test if the Timezone is currently in DST, as indicated in another answer. You could then apply the -1h offset.
Note that Joda has a minusHours() method you can use, if inDaylightTime() returns true.

Joda Datetime Constructor: Do I need to specify TimeZone for a String ending with Z?

My database stores all Datetime values as Strings in UTC. When I look at the strings they are like this
2013-05-28T01:38:13.000Z
According to documentation, 'Z' represents the timezone offset. Since there is nothing after the 'Z' does that mean there is no offset and therefore it represents UTC time?
If yes, Do I still have to specify the TimeZone in the constructor? Since the string seems to be doing that already (saying that it is UTC time) ?
DateTime myDate = new DateTime("2013-05-28T01:38:13.000Z", DateTime.UTC);
Is the second parameter neccessary?
Thanks.

Yes. You still need to pass a timezone (UTC).
The reason for this is that the string-only parameter will correctly extract the values of year, month, etc., but then interpret them as belonging to the default timezone, rather than parsing the Z+-x part.
(I'll admit it's a bit confusing.)
You can see more details in this other question with call trace, as well as the comment below for a better explanation of the meaning of the Z

XSLT - get timezone offset from locale

Is it possible in XSLT to retrieve the time zone offset for a particular locale? There is a function named in-summer-time which takes in a dateTime and a locale identifier. It returns whether the given date falls under daylight savings or not for that country.
I have a requirement where I need to calculate the offset time for a particular locale. For example, I get the local time at Chile and I need to convert it to local time in UK. I can make use of the function in-summer-time to calculate for the daylight adjustments. But, where can I get the actual offset time for Chile?
P.S.: the function adjust-time-to-timezone does not help since it requires the offset time to be passed into the function(like 2013-05-10T08:10:30-05:00). I do not have the offset time (-05:00) information before hand.

There's a Saxon extension function
saxon:adjust-to-civil-time
See http://www.saxonica.com/documentation/index.html#!functions/saxon/adjust-to-civil-time
Which looks as if it might serve the purpose.
(The heading giving the function signature in the documentation is wrong.)
For example
saxon:adjust-to-civil-time(xs:dateTime('2013-12-06T12:00:00Z'), 'America/Santiago')
returns
2013-12-06T09:00:00-03:00

Java - Creating a Calendar without a TimeZone

I would like to start by saying that I've read several threads similar to this one, but none of them really solved my problem.
I would also like to state that I've tried to use SimpleDateFormat and joda.DateTime without any success.
The problem is the following:
I have a Calendar object that holds the information about a specific date: 2008-04-30T00:00:00Z
When using the calendar.getTime() method I can get different results because I know that that method is looking for the local value
Thus:
UK: 2008-04-30T01:00:00.000+0100
US: 2008-04-30T20:00:00.000-0400
But I would like to get a Date object that holds just the Date and Time values "2008-04-30T00:00:00" ignoring completely any timezone.
How can I do that?
As I mentioned before I tried to use
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss")
but I always end up with the same results.
Any help would be really appreciated
Cheers.

Found out that you can clear the Timezone by using code below:
Calendar cal = Calendar.getInstance();
cal.clear(Calendar.ZONE_OFFSET);

Calendars and Dates mean nothing without a TimeZone.
Calendars and dates cannot exist without a timezone.
You can't ignore completely any timezone.
You can create a Calendar for Greenwich Mean Time (offset zero) like this:
TimeZone zone = TimeZone.getTimeZone("Etc/GMT");
Calendar cal = Calendar.getInstance(zone);
This represents a Date/Calendar that is only meaningful in the GMT timezone.
It sounds like you want a timestamp, which represents an instant in time.

As others have pointed out, Calendar and Date objects cannot exist without a time zone.
I believe you may want to use the LocalDateTime class introduced in Java 8 with the new time API:
LocalDateTime literal = LocalDateTime.of(2008, 4, 30, 0, 0, 0);
LocalDateTime parsed = LocalDateTime.parse("2008-04-30T00:00:00"); // ISO-8601 by default
Assert.assertEquals(literal, parsed);

Do you use a standard constructor for initializing Calendar? What if you used the constructor which allows to specify the time zone and locale?
protected Calendar(TimeZone zone, Locale aLocale)

Old, but still incorrect.
"When using the calendar.getTime() method I can get different results because I know that that method is looking for the local value"
That is a misconception. getTime() will get the Milliseconds only. Countet as GMT.
ONLY during formatting of the Output the time zone becomes relevant. Sind the original poster did not show the code, it can not be decided, where the error occurs.