Due to the limitation of date parsing on BlackBerry I'm trying to roll my own parse/deparse methods, however I seem to be falling foul of an hour's difference somewhere, somehow.
I do this:
long nowLong = System.currentTimeMillis();
String nowString = DateParser.longToString(nowLong);
Date nowDateFromString = DateParser.stringToDate(nowString);
Date nowDateFromLong = DateParser.longToDate(nowLong);
When outputted in order it produces this in console:
[139.46] 1369132556831
[139.46] 21 May 2013 11:35:56 Europe/Dublin
[139.46] Tue May 21 12:35:56 Europe/Dublin 2013
[139.46] Tue May 21 11:35:56 Europe/Dublin 2013
My simulator's time is set to 11:35 so the third statement - DateParser.stringToDate() - seems to be failing somewhere.
Here is my implementation:
public static Date stringToDate(String date) {
long l = HttpDateParser.parse(date);
Date d = new Date(l);
return d;
}
As my nowString includes the time zone I'd expect HttpDateParser.parse() to take this in to account but it seems not to be.
How can I correct this?
HttpDateParser.parse() is documented to handle "GMT" or a "TZD" which I assume to be a "time zone designator". I suspect this is expected to be the (horrible, ambiguous) abbreviation format - so for example, it might be worth trying to parse
21 May 2013 11:35:56 BST
and seeing what you get out. That would at least take you further in terms of diagnosing the behaviour of HttpDateParser. Keeping the time zone's TZDB ID is a better idea in my view, but you may well need to write your own parsing code. You still need to handle local time ambiguity though, where a particular local time occurs twice due to DST transitions.
It's not entirely clear what the input or expected output are in your case - how much control you have over the format. I'd try to use ISO-8601 as far as possible, with a time zone identifer as well if you need one. (If you're only trying to represent an instant in time, I'd use an ISO-8601 representation of the UTC instant, complete with a Z suffix to indicate UTC.)
Related
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());
my $apptStartDateTime = "20210401100000";
my $formatter = DateTime::Format::Strptime->new(pattern => "%Y%m%d%H%M%S", time_zone => "MST");
my $dt_obj = $formatter->parse_datetime($apptStartDateTime);
$dt_obj->strftime("%Y%m%d%H%M%S"), "\n"; #prints 20210401100000
# to convert to a different zone:
$dt_obj->set_time_zone("America/Los_Angeles");
$dt_obj->strftime("%Y%m%d%H%M%S"), "\n";#prints 20210401100000
The above does not convert from MST to America/Los_Angeles. Can someone please help? I am new to Perl. Also, would the above code take care of DST?
I think you meant to use US Mountain Time, which is identified by America/Denver. But even if the date-time is in US Mountain Time, that won't always give you the right answer.
If you refer to this list of tz database time zones, you'll see that
US Mountain Standard Time (MST) is UTC-7.
US Pacific Time (America/Los_Angeles) is UTC-8 in the winter, and UTC-7 in the summer.
The correct conversion of
2021-04-01 10:00:00 -07:00 (MST)
is therefore
2021-04-01 10:00:00 -07:00 (America/Los_Angeles)
DateTime properly converted the date-time.
Maybe you meant to use US Mountain Time, which is identified by America/Denver (UTC-7 in winter, UTC-6 in summer). However, that introduces an ambiguity. For one hour every year, you'll get the wrong answer due to the overlap during the DST change.
For example,
2020-11-01 02:30:00 (America/Denver)
could refer to both
2020-11-01 02:30:00 -05:00 (America/Denver) Before "fall back"
2020-11-01 02:30:00 -06:00 (America/Denver) After "fall back"
Date-times should be transmitted in UTC or provide the offset from UTC of the date-time. For example, using the standard RFC3339 format, you could use any of
2020-11-01T02:30:00-05:00
2020-11-01T07:30:00+00:00
2020-11-01T07:30:00Z
for the former and any of
2020-11-01T02:30:00-06:00
2020-11-01T08:30:00+00:00
2020-11-01T08:30:00Z
for the latter. Then, you could keep using DateTime::Format::Strptime (with %z), or use DateTime::Format::RFC3339.
I am trying to retrieve the timezone abbreviations of the local time zone by using the following code.
private func getLocalTimezone() -> String {
guard let localTimezone = TimeZone.current.abbreviation() else {
return ""
}
return localTimezone
}
But when I am in Indian time zone I am always getting GMT+5:30 where I need it as IST. Its coming correctly when I am in CST or PST. Can anyone please suggest a way to reach to the solution for this issue.
Thanks a lot in advance
This is because time zone abbreviations are locale sensitive. IST only means India Standard Time (Asia/Kolkata) in India. In other parts of the world, it could mean Israel Standard Time, or Irish Standard/Summer Time. Here's a site that shows you the list of abbreviations. You can see for yourself how ambiguous they can be.
This is why abbreviation() takes into account the region of your phone, i.e. this setting:
abbreviation() will give you "IST" if your device's region is India. If your phone is somewhere else, it shows "GMT+5:30" because that is the safest, most unambiguous option.
If you want it to output IST no matter where your device is, you need to hard code this by creating a dictionary of time zone identifiers to abbreviations that you want. There is a built in abbreviationDictionary that goes the other way - abbreviations to identifiers. You can search it, and it will work for IST (Asia/Kolkata), but might not work for whatever other time zone that you are interested in.
let abbreviation = TimeZone.abbreviationDictionary
.first(where: { $1 == TimeZone.current.identifier })?.key
and I'm not sure whether the contents of this dictionary will stay the same in future versions of iOS. Use it at your own risk.
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()
From what I understand, calling
NSLog(#"Local Time Zone %#",[[NSTimeZone localTimeZone] name]);
gives you the local time zone of the device. What it's giving me is "US/Central", and I can't find that anywhere in the list of abbreviations in [NSTimeZone abbreviationDictionary], or the list of time zone names in [NSTimeZone knownTimeZoneNames]. Where is this one coming from? I need to pass the current device time zone to a Rails app, and it understands things like "Australia/Sydney" or "America/Chicago", but not "US/Central".
How do I take what localTimeZone is giving me and convert it to a string that Rails can understand (i.e. any time zone in knownTimeZoneNames, which is supposed to be all time zone names that the system knows about?)
You're likely using ActiveSupport::TimeWithZone without having required the tzinfo gem:
$ irb -rrubygems -ractivesupport -rtzinfo
>> Time.send(:get_zone, "US/Central").now
=> Tue, 17 Nov 2009 04:27:23 CST -06:00
If you don't require tzinfo, you'll only get a subset of timezones which is fairly useless.
EDIT: Just to avoid confusion, the reason I used the private Time#get_zone API is because that's what's being used behind the scenes when you call Time#zone=. If you don't require tzinfo, calling Time.send(:get_zone, "US/Central") returns nil.
Are you getting that from within the simulator?
If so what does this command returns for if you run it from a terminal?
$ systemsetup -gettimezone
The timezone setting GUI in Mac OS 10.5 would set timezones to US/*. If you manually set it from the console you can set it to one of the expected timezones.
Run this to get a list of the valid, and notice that US/Central isn't among them.
$ systemsetup -listtimezones
Run this to set it to America/Chicago
$ systemsetup -settimezone America/Chicago