Develop Reference

Instant.now() returns wrong UTC time ( E.g. 14:24 instead of 02:24 ) +12 hours ahead

So I am trying to get the current UTC time in Java ( I'm using Java 7 with ThreeTenAbp ). I have tried the following calls and all of them return the time in UTC + 12 hours which is not the real UTC time as I have checked online through various source that provide current UTC time.
Instant.now().atZone(ZoneId.of("UTC")).toString();
Instant.now().toString();
Date date = new Date();
SimpleDateFormat dateFormat = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");
dateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
I don't know why these are reporting the wrong UTC time given that I'm explicitly specifying the UTC timezone, except for the second one. I also think it's unlikely that all of these methods of getting the UTC time yield the wrong result so I am wondering what I am doing wrong.

While I cannot be sure, of course, the very likely reason for the behaviour you have observed is that you are running your program on a computer or a device the clock of which is set incorrectly. Both Instant.now() and new Date() pick up the time from the system clock, so this would explain nicely.
You may object and ask: How could I set the system clock 12 hours ahead? How could I not discover? While there could be many explanations for this, the two obvious ones are:
Setting the system clock 12 hours wrong is not hard, that could easily happen by mistake. If your system is showing the time on a 12 hour clock (digital or analog), it will appear to show the correct time even though the time has been set 12 hours ahead. You will be able to notice that the date is one day ahead every day after 12 noon, though.
Your device may have an incorrect time zone setting so that when you set the time to the correct time in your time zone, this really means setting it to the wrong time on the time line. For example: Your device time zone is set to America/Los_Angeles which for a couple of days still is at UTC-8. You are in Dubai, where the current time is UTC+4. At 10 AM in Dubai you set the device time to 10:00, but your device understand it as 10:00 Los Angeles time, which is the equivalent of 22:00 (10 PM) Dubai time. So in this way your clock accidentally gets set 12 hours ahead. And as long as no one correct the time zone setting, it’s hard to detect that anything is wrong. Still it will cause Instant.now() and new Date() to give the incorrect results you observed.

I tested your code,found your code is OK.Try again,or you can try the following code:
Instant.now().atOffset(ZoneOffset.ofHours(0));

When you print Instant.now().toString(), are you sure the result is not in UTC? Because Instant always works in UTC.
The only thing I can guess is that you're printing the java.util.Date directly, and this class has a terrible toString() method which takes the JVM default timezone.
Maybe if you edit your question and add the inputs and outputs for each case, we can help you better. Because I can't reproduce your problem.
By the way, the current UTC time is (when I tested the code) 2018-03-08T14:47:08.886Z (14:47, or 02:27 PM). If your problem is to print the time in AM/PM format, then you could use a DateTimeFormatter:
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'hh:mm:ssaX");
String formatted = ZonedDateTime.now(ZoneOffset.UTC).format(fmt);
Using hh gives you the hour in AM/PM (1 to 12), instead of 0 to 23 (which is the default, and also the value returned by HH pattern). I also added a, which gives you AM or PM, to not make the output ambiguous.

Joda: get local milliseconds of specific timezone

I never would believe that this could amount to being such a hassle. I am trying to make a clock that always displays the local time in specific timezones.
My laptop is currently set in GMT0 timezone (UK).
I want to get the milliseconds of the timezone "Europe/Stockholm".
So let's say it's 17:00 here in the UK I would like to get the milliseconds corresponding to 18:00 which would be the Swedish time.

The time in milliseconds as used by Date is independent of the time zone. Only when you print (or parse) a time, you use a DateFormat that is localized, so it ensures you get the time in the specific timezone.

When time is represented as milliseconds (or seconds or nanoseconds, etc), that is almost always milliseconds since some epoch. In the case of unix and java, this is midnight Jan 1, 1970 UTC.

Time zones are generally arranged as a round number of hours relative to UTC. In certain time zones it's not a round hour but 30 minutes, 15 minutes or 45 minutes from a round hour.
Nevertheless, for any time unit below a minute, all those time zones match UTC exactly.
Therefore, whatever the current second or millisecond is in Sweden, it is the same as it is, for example, in Nepal, whose time zone is 5:45 minutes from UTC.
When you work with an object that allows you to retrieve the separate fields of the given time, the milliseconds field will usually reflect just the number of milliseconds since the beginning of the current second, not the number of milliseconds since midnight. Therefore it will never be more than 999, and it will be the same the world over.

After reading the answers here and discovering another route, this is what finally worked for me.
DateTime curDateTime = new DateTime();
int offset = DateTimeZone.forID("Europe/Stockholm").getOffset(curDateTime.getMillis());
long milli = (curDateTime.getMillis()+offset);

C# Ticks convert to java util date; date is 5 hours behind why?

I need help. I have been trying to figure out why java util date is 5 hours behind after converting from C# ticks.
in C#, the date is 6/8/2013 11:02:07 AM, I convert this date into ticks then pass it to java as long.
code snippet:
taken:
- long TICKS_AT_EPOCH = 621355968000000000L;
- long TICKS_PER_MILLISECOND = 10000;
java.util.Date date = new java.util.Date((ctime - TICKS_AT_EPOCH) / TICKS_PER_MILLISECOND);
Now java util date is Sat Jun 08 06:02:07 CDT 2013
Notice that the hour is 5 hours difference.
Any suggestions why?

You are constructing a java.util.Date based on milliseconds since 1/1/1970 UTC. You appear to be correcting from the fact that .net's System.DateTime.Ticks are based on 1/1/0001 and are 10,000 ticks to a millisecond. That is correct, but you have forgotten to adjust to UTC.
In .Net, the value coming from DateTime.Ticks is highly dependent on the DateTime.Kind property. There are three possible kinds of DateTime values.
DateTimeKind.Utc - This kind means that the value represents UTC time. It usually comes from a call to DateTime.UtcNow, but can also be constructed directly, and often is. For example, you might be retrieving UTC times from a database. You can feed the ticks from here directly into your conversion, and it will work.
DateTimeKind.Local - This usually comes from a call to DateTime.Now. The values are representative of the local time zone. You will need to convert to UTC before checking the ticks. You can do the following:
DateTime dt = DateTime.Now;
int utcTicks = dt.ToUniversalTime().Ticks;
Be aware that if the time happens during a daylight saving "fall-back" style transition, the result might be incorrect. The DateTime class has no idea about time zones. It just reflects the current local clock. If the value in dt is ambiguous, ToUniversalTime() will assume that the value is representative of standard time, even if you just retrieved it while in daylight time. This is just one of the many confusing and probablematic aspects of DateTime in .net.
DateTimeKind.Unspecified - This is the most common kind of DateTime you will encounter, and usually comes from DateTime.Parse() or a constructor like new DateTime(...). Unfortunately, there is nothing in here that will tell you about the time zone these dates are representative of. You can still try calling .ToUniversalTime(), but the framework will make the assumption that these times are representative of your local time zone, as if the kind was Local. That assumption could be completely wrong, depending on how you sourced the data. There really is no safe way to transform an Unspecified DateTime to a UTC value (ticks or otherwise).
There are some solutions, such as using DateTimeOffset instead of DateTime, or using the Noda Time library instead of the built-in types. You can read more about these problems here and here.

The time is not 5 hours behind, it's exactly the same time. The problem is with the way you print it.
You need to tell C# and Java to use the same time-zone when converting the date to string. One of them is using UTC and the other CDT.

java.util.date automatically corrects for your time zone. See this question: How to set time zone of a java.util.Date?

The ctime is UTC (Universal Coordinated Time), which is a time standard referenced to Greenwich. You're expressing your time in Central time. There's your difference.

Set Time Without Knowing Date

I want to be able to store time values in a mysql database without actually knowing a specific date they are associated with. I am using the java.sql.time to store the data.
long timeInMillis = 43200000; //This is 12 hours in milliseconds.
Time time = new Time(timeInMillis);
For whatever reason this is giving me a time of 07:00:00 and it should be 12:00:00. I'm assuming this is because when setting a time variable it is based on the amount of time past a specific date. How do I set a time variable without actually using a pre-defined date?
The reason I am doing this is because I want to store a week day and a time range in a database. So Sunday between 12 and 1 would be 0 between 12:00:00 and 13:00:00. I want to be able to compare an actual date value against the database and see if the date falls between the time periods based on the dates day of week regardless of the month or year. Storing full dates in the database for each possible weekday and time would result in thousands of unnecessary entries.

For whatever reason this is giving me a time of 07:00:00 and it should be 12:00:00. I'm assuming this is because when setting a time variable it is based on the amount of time past a specific date
Can happen due to TimeZone difference. Check for timezone information while saving and retrieving values.

This is likely a timezone issue, but I solved the problem by passing the time values into the database as a string. It is probably best to use a physical string in this instance anyways unless timezone properties are important.
String startTime = "12:00:00";
String endTime = 01:00:00;
If timezone is important I assume the best method to use unless you are preparsing your date object would be to set the timezone directly in your mysql statement for the current session. More details can be found here: How do I set the time zone of MySQL?
EDIT: Turns out in the end this wasn't actually a time zone issue (although in other circumstances it could be, so don't discredit adjusting for time zone). I was calculating the time in milliseconds incorrectly.

Joda Time subtracting 24 hours from an instance of MutableDateTime, I would like to know why

I do not understand why MutableDateTime.setDate() is setting the time to "yesterday" (see the log timestamp hours - it is 20:28). Is this timezone related? Do I need to set something on the formatter?
I would expect that after calling setDate with "10/27/2010", the date would be the same as the parsed date 00:00 EDT 10/27/10, instead of 20:28 EDT 10/26/10. This is 24 hours ago from "now".
What am I missing here, or how should I edit the code to get the desired result? I am new to Joda Time, and would like to solve this mystery.
DateTimeFormatter dateFormatterJ = DateTimeFormat.forPattern("MM/dd/yyyy");
DateTimeFormatter timestampFormatJ = DateTimeFormat.forPattern("HH:mm zzz MM/dd/yy");
MutableDateTime startDate = new MutableDateTime();
log.info("parsed date " +
timestampFormatJ.print(dateFormatterJ.parseMutableDateTime(startDateString)));
startDate.setDate((dateFormatterJ.parseMutableDateTime(startDateString)));
log.info("startDate: " + timestampFormatJ.print(startDate));
In this case, startDateString is simply "10/27/2010".
here is the log output:
10-27 20:28:55 INFO parsed date: 00:00 EDT 10/27/10
10-27 20:28:55 INFO startDate: 20:28 EDT 10/26/10
Thanks

The simple answer would be, because the javadoc says so.
public void setDate(ReadableInstant
instant)
Set the date from another
instant. The time part of this object
will be unaffected.
Parameters:
instant - an instant to copy the date
from, time part ignored
Throws:
IllegalArgumentException - if the
object is invalidobject is invalid
When Joda says 'Date' it means the human meaning of the word Date. "The year-month-day portion of this value", not the logical equivalent of a java.util.Date. (the whole point of joda being to introduce some natural, sensible, semantics to handling date and time.)
EDIT:
To answer your 'how to fix' question, simply do:
MutableDateTime startDate = new MutableDateTime(dateFormatterJ.parseMutableDateTime(startDateString));
Or else manually zero out the time portions of course.
EDIT 2: Hmm, I apparently did not read carefully enough, this is only half of the answer. Will check.
EDIT 3: well this bugged me so much that I took a minute to look for it.
public void setDate(final ReadableInstant instant) {
long instantMillis = DateTimeUtils.getInstantMillis(instant);
Chronology instantChrono = DateTimeUtils.getInstantChronology(instant);
DateTimeZone zone = instantChrono.getZone();
if (zone != null) {
instantMillis = zone.getMillisKeepLocal(**DateTimeZone.UTC**, instantMillis);
}
setDate(instantMillis);
}
For some reason, it's rolling your absolute time forward into UTC before setting the date. So you give it 10/27/2010 00:00 EDT and it sets the absolute magnitude of time to the number of milliseconds that represent 10/27/2010 00:00 UTC, which of course is only 6 or 7 PM the day before. Then it finds the EDT date value of that to be 10/26.
Couldn't say if that's somehow intended or if it's a bug that's been there for 2 years or what.)

When parsing a string that does not contain a GMT offset or time-zone ID, you must do one of three things:
do nothing, and accept that the string is parsed in the default time zone
specify the time zone to parse in using withZone() on the formatter
use parseLocalDate() instead of parseMutableDateTime()
The last is the preferred solution, as it correctly parses the data that was actually input, which was a date without time, offset or zone.
Using parseLocalDate() in the test code correctly parses the date.