1

I want to convert a specific date string with a specific timezone to another timezone in another format. Here is an example:

var date = '2020-04-09 17:10:57'; //Date in YYYY-MM-DD HH:MM:SS format
var timezone = 'America/New_York'; //Timezone of the given var date

Now I want to convert this date in the timezone to another so for example i have:

var convert_to_timezone = 'Europe/Berlin';

I just know, how to get the current users date, but I dont know, how to convert exactly this date with exactly this timezone to another. I also want to respect daylight saving time.

The output should be:

//2020-04-09 23:10:57

Thanks in advance, you would really help me with an answer because I tried this 2 hours and dont get it :(

bewikec973
  • 13
  • 2
  • does this need to be done in vanilla js? or would you consider using a library like https://moment.github.io/luxon/ ? – WillD Apr 09 '20 at 00:03
  • @WillD vanilla js would be good, but if there is no other way, than i would also do it with a library. i already searched for some librarys but couldn't find anything good, doing exactly what i want. – bewikec973 Apr 09 '20 at 00:11
  • Take a look at this: https://stackoverflow.com/questions/10087819/convert-date-to-another-timezone-in-javascript – WillD Apr 09 '20 at 00:14
  • @WillD i already saw this topic, but my problem is, that i just see in this how to convert the date in users timezone to another. but i dont know, how to convert a string with a timestamp in a specific format with a timezone to another one. – bewikec973 Apr 09 '20 at 00:19

2 Answers2

3

Luxon is a modern re-write of Moment. If you go that direction, here's working code:

var DateTime = luxon.DateTime;

var date = '2020-04-09 17:10:57';
var timezone = 'America/New_York';
var format = 'yyyy-MM-dd HH:mm:ss';

var luxonTime = DateTime.fromFormat(date, format, {zone: timezone});

var berlinTime = luxonTime.setZone('Europe/Berlin').toFormat(format);

console.log(berlinTime);
<script src="https://cdn.jsdelivr.net/npm/luxon@1.23.0/build/global/luxon.min.js"></script>

On the differences between Luxon and Moment: https://github.com/moment/luxon/blob/master/docs/why.md

WillD
  • 5,170
  • 6
  • 27
  • 56
  • Good point on the parser, i'll edit the solution. Re PS: Do you know of a vanilla js way to do this? In particular managing daylight savings time (for NYC) and whatever other locale based rules exist for the Berlin side of the equation? – WillD Apr 09 '20 at 04:03
  • No. I believe Luxon relies heavily on the [*Intl.DateTimeFormat* object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat), which doesn't do parsing. It's OK for timezone shifting the output, but I don't know how Luxon leverages it for parsing (though I haven't looked either). So you might look at the internals of Luxon. – RobG Apr 09 '20 at 04:53
  • @RobG - Luxon has its own string parser, and it "abuses" the Intl APIs to build up a cache of time zone information. It's non-trivial but works. Isaac did a pretty amazing job there. :) – Matt Johnson-Pint Apr 09 '20 at 16:49
1

I think use moment timezone is much easier and less verbose.

var newYork = moment.tz("2020-04-09 17:10:57", "America/New_York");
var berlin = newYork.clone().tz("Europe/Berlin");
console.log(berlin.format())
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.28/moment-timezone-with-data.min.js"></script>

Here is an example

RobG
  • 142,382
  • 31
  • 172
  • 209
Andy Song
  • 4,404
  • 1
  • 11
  • 29
  • thanks, i'll give it a try and let you know. but what i have to download? and do i have to download it new every x years? or will it work when i download it without data. – bewikec973 Apr 09 '20 at 00:23
  • just use the [full](https://momentjs.com/downloads/moment-timezone-with-data.js) version – Andy Song Apr 09 '20 at 00:24
  • @bewikec973 you also need the [moment js library](https://momentjs.com/downloads/moment.js). and the order is `momentjs` first and then `momentjs timezone` second. Just like the example link I provided in the answer. – Andy Song Apr 09 '20 at 00:29
  • ah, yeah i understood. i'll test it later because its late here in 'Europe/Berlin' ;) – bewikec973 Apr 09 '20 at 00:44
  • please, upvote, and accept my answer, if it helped you – Andy Song Apr 09 '20 at 00:45
  • yeah, i'll do later when i tested it. ;) – bewikec973 Apr 09 '20 at 00:52
  • Given that the input string is not strictly compliant with ISO 8601 you should be providing the input format. And since you don't provide the output format, it's not consistent with the OP. When those factors are considered, the moment.js version is only a few characters shy of the Luxon version. And given that Luxon.min is 70kB and the two moment.js mins come to 249kB, you might put Luxon ahead. Though it does rely on the host having a fairly recent implementation of the Intl.DateTimeFormat object. – RobG Apr 09 '20 at 04:10
  • FYI - Luxon is in the Moment family (authored by Moment maintainer Isaac Cambron). Generally speaking, the Moment team recommends Luxon for all new projects unless there's a particular Moment feature not yet implemented in Luxon. Moment and Moment-Timezone are basically in maintenance mode at this point. In particular, Moment-Timezone has no plans to advance beyond its 0.x status. – Matt Johnson-Pint Apr 09 '20 at 16:52
  • @MattJohnson-Pint—it seems built–in timezone support is not up–to–date, e.g. the offset for Pacific nations like Pacific/Samoa is set to -11 (which is consistent with the offsets [listed on Wikipedia](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)), but it changed to +13 at the start of 2011. It also doesn't recognise Samoa's daylight saving offset. So how reliable is the Intl object as a source of timezone offset information? (PS I'd pm you but can't see how to do it on SO). – RobG Apr 14 '20 at 02:14
  • @RobG `Pacific/Samoa` links to `Pacific/Pago_Pago` (American Samoa) which is still UTC-11. You're looking for `Pacific/Apia`, which is UTC+13 (UTC+14 for DST). Samoa != American Samoa. The Intl data is as good as the underlying implementation, which is somewhat uncertain, yes. But at least evergreen browsers have a path to keeping it updated. Not sure if they do. (Also, there is [an active bug](https://bugs.chromium.org/p/chromium/issues/detail?id=364374) about some links not working, such as `US/Pacific`) You can DM me on Twitter at https://twitter.com/messages/compose?recipient_id=57677826 – Matt Johnson-Pint Apr 14 '20 at 16:49