Same date in different time zone - date

My question is how can I get the same day, month, year, hour, minutes, seconds in a different time zone, for example:
var now = moment().valueOf();
var result1 = moment(now).format('DD-MM-YYYY HH:mm:SS Z');
In my time zone I get some this like this:
18-02-2015 21:08:34 +01:00
So how can I change only time zone without changing other values (days, months, ..., minutes, ...)
I want to get some thing like this:
result2: 18-02-2015 21:08:34 +01:00
result3: 18-02-2015 21:08:34 +10:00
result4: 18-02-2015 21:08:34 +05:00
result5: 18-02-2015 21:08:34 -06:00
result6: 18-02-2015 21:08:34 -11:00
Thanks in advance

Here's how you could do what you are asking:
// get a moment representing the current time
var now = moment();
// create a new moment based on the original one
var another = now.clone();
// change the offset of the new moment - passing true to keep the local time
another.utcOffset('+05:30', true);
// log the output
console.log(now.format()); // "2016-01-15T11:58:07-08:00"
console.log(another.format()); // "2016-01-15T11:58:07+05:30"
However, you must recognize two important things:
The another object no longer represents the current time - even in the target time zone. It's a completely different moment in time. (The world does not synchronize local clocks. If it did, we'd have no need for time zones!).
For this reason, even though the above code satisfies the question that was asked, I strongly recommend against using it. Instead, re-evaluate your requirements, as it's likely they are misunderstanding the nature of time and time zones.
A time zone cannot be fully represented by an offset alone. Read "Time Zone != Offset" in the timezone tag wiki. While some time zones have fixed offsets (such as +05:30 used by India), many time zones change their offsets at different points throughout the year to accommodate daylight saving time.
If you wanted to account for this, you could use moment-timezone instead of calling utcOffset(...). However, the issue in my first bullet would still apply.
// get a moment representing the current time
var now = moment();
// create a new moment based on the original one
var another = now.clone();
// change the time zone of the new moment - passing true to keep the local time
another.tz('America/New_York', true); // or whatever time zone you desire
// log the output
console.log(now.format()); // "2016-01-15T11:58:07-08:00"
console.log(another.format()); // "2016-01-15T11:58:07-05:00"

The most-voted answer is messy IMO. Here's a cleaner solution - similar to BlueSam's answer, but safer:
const myTime = moment.tz('2016-08-30T22:00:00', moment.ISO_8601, 'America/Denver')
myTime.format() //2016-08-30T22:00:00-06:00
const sameTimeDifferentZone = moment.tz(myTime.format('YYYY-MM-DDTHH:mm:ss.SSS'), moment.ISO_8601, 'America/New_York')
sameTimeDifferentZone.format() //2016-08-30T22:00:00-04:00

After reading the above comments, I thought I'd add in based on Joao's answer.
In my case I was trying to use a preexisting moment date with a timezone and converting it to another timezone while retaining the original date value (as asked in the question).
var newTimezone = 'America/Denver';
//date - contains existing moment with timezone i.e 'America/New_York'
moment.tz(date.format('YYYY-MM-DDTHH:mm:ss'), 'YYYY-MM-DDTHH:mm:ss', newTimezone);

From the moment docs: http://momentjs.com/timezone/docs/
reference moment-timezone-with-data.js and specify which timezone to go to, like so:
moment(date).tz("America/Los_Angeles").format()

Related

How to set up only time in date-fns and still keep the timezone in javascript

I currently have the following use case:
User receives a date in UTC from the backend
This date is transformed into local time for displaying purposes
The date is displayed in different inputs. One input for date and other for time
User can select time independently
The date should be sent back to the backend in UTC format as well
I'm not very experienced with time zones and I'm getting beaten by trying to allow the user to set up only the time (or date) in a datetime field.
My pseudo code is the following:
When receiving the from backend simply convert the date to show it to the user, making the orignal date stay in UTC
When the user picks the hour and minute (all in one action) use setHours and setMinutes from date-fns library
Use native toISOString() to set in models
Code so far [playground]:
import { utcToZonedTime, format } from "date-fns-tz";
import { setHours, setMinutes } from "date-fns";
const UTCStringdate = "2022-04-06T10:00:00.000000Z";
const userTimezone = "Asia/Bangkok";
const localizedTime = utcToZonedTime(UTCStringdate, userTimezone);
// Prints the correct information
// 10:00 in UTC is equal to 17:00 in Bangkok
console.log(format(localizedTime, "HH:mm"));
// Now I expext to set only the `minutes` and `hours`
// to this `localizedTime` so that I can update the backend
const [hours, minutes] = "10:30".split(":");
// Somewhere over here the `setHours` and `setMinutes`
// is turning the Date object into my own timezone
// and not using `Asia/Bangkok` timezone anymore
let newTime = setHours(localizedTime, hours);
newTime = setMinutes(newTime, minutes);
// Now I expect to print 17:30 since we only
// set up 30 minutes forward than the original one
// but it ends up printing 10:30
console.log(format(newTime, 'HH:mm'));
I understand that somewhere along the way (most likely in setHours and setMinutes) the date-fns library turns back the localizedTime back into my own timezone, completely ruining the idea of turning the Asia/Bangkok time into UTC.
Questions
First, is this the best approach to manipulate only the time part of a date when considering timezones? If not, anyone can point me to articles? I wasn't able to find anything on the topic
Second, how can I use setHours and setMinutes and still maintain the timezone?
There are no multiple time zones in JavaScript. There is UTC and there is your local one. What date-fns-tz does, is adjusting the time to the chosen user time zone. In your example, you can see this when printing both the original and the localized time
const utcTime = new Date(UTCStringdate);
console.log(utcTime.toISOString()); // -> 2022-04-06T10:00:00.000Z
console.log(localizedTime.toISOString()); // -> 2022-04-06T14:00:00.000Z
To solve your issue, convert UTC time to users time and let the user to adjust hours and minutes in his local time zone. After that, convert the time object back to UTC using zonedTimeToUtc
newTime = zonedTimeToUtc(newTime, userTimezone);
and then use newTime.toISOString() to send it back to the server.
console.log(newTime.toISOString());

Calculate the time difference

I am trying to calculate time difference between 2 ZonedTime dates in Scala. I am receiving dates in "2021-03-19T15:39:42.834248-07:00" format as a String. I need the difference in seconds between 2 dates in Scala. How to convert the string to zoned time and calculate the difference?
You'll want to use the between() method as offered on a temporal.ChronoUnit.
import java.time.ZonedDateTime
import java.time.temporal.ChronoUnit.SECONDS
val start = ZonedDateTime.parse("2021-03-19T15:39:42.834248-07:00")
val stop = ZonedDateTime.parse("2021-03-19T15:49:42.834248-08:00")
val secsBetween:Long = SECONDS.between(start, stop) // 4200
An alternative is to use the until() method on the ZonedDateTime instance itself.
val secsBetween:Long = start.until(stop, SECONDS) //same result
[Java syntax, not Scala.]
tl;dr
Duration
.between
(
OffsetDateTime.parse( "2021-03-19T15:39:42.834248-07:00" ) ,
OffsetDateTime.parse( "2021-03-19T15:49:42.834248-08:00" )
)
.toString()
See this code run live at IdeOne.com.
PT1H10M
…which in standard ISO 8601 format means 1 hour and 10 minutes.
Details
The Answer by jwvh is close, but I would change a couple things.
OffsetDateTime, not ZonedDateTime
Your input strings have only a mere offset-from-UTC but no time zone. So parse those as OffsetDateTime.
An offset is simply a number of hours-minutes-seconds ahead or behind the baseline of UTC, the line drawn through Royal Observatory, Greenwich. An example of an offset is -07:00 which means seven hours behind UTC.
A time zone is much more. A time zone is history of the past, present, and future changes to the offset used by the people of a particular region. A time zone has a name in format of Continent/Region. Given our example above, on some dates, several time zones may share the offset of -07:00, including America/Dawson, America/Los_Angeles, America/Phoenix, America/Boise, and more.
OffsetDateTime odt = OffsetDateTime.parse( "2021-03-19T15:39:42.834248-07:00" ) ;
Duration
Represent a span-of-time using Duration, on the scale of hours-minutes-seconds-nanos.
Duration d = Duration.between( sooner , later ) ;
Generate text in standard ISO 8601 format.
String output = d.toString() ;

DateTimes.toUtc() not working as expected

void main() {
var foo = DateTime(2000).toUtc();
var bar = DateTime.utc(2000);
assert (foo != bar);
}
foo and bar should be equal but they aren't, can anyone tell me what am I doing wrong with toUtc(). As far as I know DateTime(2000) returns the DateTime in local time zone and toUtc() converts that to UTC, but it doesn't do that.
Thanks to someone who deleted the answer after posting this link. And thanks to #lrn for answering it:
DateTime(y, m, d).toUtc() finds the y-m-d time in the local time-zone and then creates a UTC date at the same point in time. So, if I'm in the UTC+2 time zone, and I do DateTime(2019, 04, 02).toUtc(), I start with the local time 2019-04-02T00:00:00+02:00, and then find that the corresponding UTC-time is 2019-04-01T22:00:00Z. That's the same point in time in a different time zone, it answers the question "when the local time is 2019-04-02T00:00:00, what is the time in the UTC time zone".
When you do DateTime.utc(2019, 04, 02), you get the point in time where the UTC clock showed 2019-04-02T00:00:00Z. If I do toLocal() on that, I'd get the local time 2019-04-02T02:00:00+02:00.

Calculating Seconds Until a Given Date and Time in Joda Time

I am trying to use the Joda Time library to help me schedule sending some messages to an Actor in Akka.
I would like to schedule sending emails every day at 8:30 AM. To do this, I have to tell the scheduler how many seconds (or milliseconds) to wait until the next message is sent.
I would like to account for daylight savings (to make sure it always fires around 8:30, and not 7:30 or 9:30) so I will use LocalDate and LocalTime.
So, basically, I have:
targetDate = LocalDate.now().plusDays(1) and targetTime = new LocalTime(8, 30)
and
rightNow = LocalDateTime.now()
I was wondering what is the best way to compose a targetDateTime based on targetDate and targetTime so I can use it to compute the time difference with rightNow
I know I can create a new LocalDateTime extracting all the values for the constructor from my targetDate and targetTime but: is there a more elegant way?
So far, I have settled for:
targetDateTime = targetDate.toLocalDateTime(targetTime)
secondsToWait = Seconds.secondsBetween(rightNow, targetDateTime)
Getting targetDateTime is easy if you have the targetDate and targetTime (as given in your question) :
targetDateTime = targetDate.toDateTime(targetTime);
Getting the seconds of the Duration between now and targetDateTime:
new Duration(new DateTime(), targetDateTime).getStandardSeconds();
The method is called standard seconds because it assumes every second to be a standard second of 1000 milliseconds. As its javadoc says, currently all Chronologies only have standard seconds.
But you can also simply use milliseconds (no conversion assumptions needed) :
new Duration(new DateTime(), targetDateTime).getMillis();
Disclaimer : I only just saw this was a scala question, so you may have to correct for any syntax differences, since I'm not versed in scala.

Is there a class in JDK to represent an hour of the day, but not necessarily a specific hour at a specific date?

Is there a class in JDK or Guava to represent an hour of the day, but not necessarily a specific hour at a specific date?
If not, why?
In JDK 1.3-1.7, the answer is no. A specific time within a day is much easier to calculate then date, because you don't have to deal with leap year, leap month, such headache stuff. A simple integer is just enough. When you need to convert the time to a locale string, using SimpleDateFormatter or whatever, you can simply convert the time to a Date, just ignore the date part:
int time = 8 * 60 + 34; // 8:34 am
Date date = new Date(60000L * time);
Reset the time zone to +0, and pass the date to the formatter:
SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("GMT+0"));
sdf.format(date);
You could simply wrap a byte into a class and every time that the current hour passes 23 within your increment() (or appropriate name) method, set the value of the byte to 0, and whenever the value passes below 0 in your decrement() (or appropriate name) method, set the value of the byte to 23.
As far as I know, there is not a specific class representing Hour (in the JDK or Guava), but there are easy to use classes to fetch the hours from a specific instance of time (which is what I am assuming you are after with this question).
You could use JODA-Time, as Paŭlo Ebermann mentions, but that is an external library. Within the JDK, there is a class called Calendar, which has many useful methods.
To get the hour of a long representing the current time, you could do this:
Calendar c = Calendar.getInstance();
c.setTimeInMillis(System.currentTimeMillis());
int hour = c.get(Calendar.HOUR); //returns 0-11
int hourOfDay = c.get(Calendar.HOUR_OF_DAY); //returns 0-23