如何在时区之间正确转换时间? [英] How to convert time correctly across timezones?

查看:83
本文介绍了如何在时区之间正确转换时间?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设美国加利福尼亚州的用户选择日期,时间和时区:



全球啤酒马拉松赛开始于 8/15/2013 10:00 am,UTC-08:00



另一个在欧洲的用户打开显示此日期和时间的页面。他不想做时间计算(已经很少的啤酒)。他只想看到这个日期和时间:



8/15/2013 19:00



鉴于浏览器收到用户在加利福尼亚输入的日期和时间信息:



有一种方法,在javascript中 没有外部Web服务,要做正确的转换?也就是说,为了检测UTC-08:00的上午10点实际上是UTC-07:00,因为它是夏令时。



也许我错了解这个从一开始,但我不想让输入的用户考虑他是否应该选择UTC-08:00(PST)或UTC-07:00(PDT)。我认为,由于CA的标准时区是PST,所以在夏季,人们不会转向思考PDT。或者他们?



在中欧,标准日期为UTC + 01:00,夏令时为UTC + 02:00。因此,CA和欧洲之间的差异应该是9个小时,除了一个或一个其他区域在标准和夏令时模式之间切换的两个时期之外。



更新:



经过一些思考和阅读评论之后,我最理想的需求是这样的:

  var utcOffset = f('2013-08-15T10:00','America / Los_Angeles'); 
// utcOffset ==-07:00
var utcOffset = f('2013-11-15T10:00','America / Los_Angeles');
// utcOffset ==-08:00

到目前为止,它看起来像Guido Preite建议的 moment.js / timezone plugin 可以做到这一点(或多或少)。



使用浏览器API的任何其他方式?

解决方案


是有一种方法,在javascript中,没有外部Web服务,要做正确的转换?也就是说,为了检测到UTC-08:00应该是UTC-08:00上午10点,因为它是夏令时。


10:00-8和10:00-7是两个不同的时刻。它们分别等于18:00Z和17:00Z(Z = UTC)。当您使用偏移量进行测量时,夏令时不会进入图像。我假设由于CA的标准时区是PST,所以在夏季,人们不会转向思考PDT。或者他们吗?!


一般来说,人们只是想想在太平洋时间,这意味着PST在冬天, PDT在夏天。但电脑更精确。当你看到PST,这意味着UTC-8。当你看到PDT,这意味着UTC-7。标签使用一个表单同时引用另一个表单的偏移将无效。



时区缩写可能是模糊的。理想情况下,当以编程方式引用该区域时,应使用IANA区域名称,例如 America / Los_Angeles 。但是,在没有库的所有JavaScript运行时中,目前都不可能。 (他们正在努力解决这个问题。)


在中欧,标准日期为UTC + 01:00,夏令时为UTC + 02:00。所以CA和欧洲之间的差异应该是9个小时,除了一个或者另一个区域在标准和夏令时模式之间切换的两个时期之外。


正确。它们可以是8,9或10小时。他们切换到完全不同的时间,所以不要试图自己管理。


到目前为止,它看起来像是moment.js / timezone插件,由Guido Preite建议能够做到这一点(或多或少)。


Moment-timezone 是一个很棒的图书馆。但是,从您描述的场景中,我不认为您需要担心时区转换与您正在考虑的那样多。看看你可以遵循这个逻辑:


  1. 加利福尼亚州的用户将日期和时间输入到一个文本框中。

  2. 您将该文本框值读入字符串,并将其解析为日期:

      var dt =新日期(8/15/2013 10:00); 

    或使用moment.js:

      var m = moment(8/15/2013 10:00,M / D / YYYY HH:mm); 


  3. 由于这是在用户的计算机上完成,JavaScript会自动假设这是一个本地日期和时间。您不需要提供任何偏移量或时区信息。


  4. 这意味着由于DST转换,输入的时间可能无效或不明确。 JavaScript在处理方面做得不是很好,实际上你会在不同的浏览器上获得不同的结果。如果你想要明确,那么你会提供一个偏移量。

      // PST 
    var dt = new Date (3/11/2013 1:00 UTC-08:00);

    // PDT
    var dt = new Date(3/11/2013 1:00 UTC-07:00);


  5. 一旦您有日期 (或时刻),那么您可以评估其UTC等效值:

      var s = dt.toISOString(); // 2013-08-15T17:00:00Z 

    它与moment.js是一样的,但你将有更好的浏览器支持:

      var s = m.toISOString(); // 2013-08-15T17:00:00Z 


  6. 您将UTC值存储在数据库。


  7. 中欧其他用户正在加载数据。


  8. 您可以在JavaScript中将其进入日期时刻

      var dt = new Date(2013-08-15T17:00:00Z); 

    或与moment.js(再次,更好的浏览器支持)

      var m = moment(2013-08-15T17:00:00Z)


  9. 由于JavaScript知道本地计算机的时区规则,您现在可以显示此日期,并显示中欧时区:

      var s = dt.ToString(); //浏览器特定输出
    // ex:Thu Aug 15 2013 19:00:00 GMT + 0200(中欧夏令时间)

    或使用moment.js,您可以更好地控制输出格式

      var s = m.format(DD / MM / YYYY HH:mm); //15/08/2013 19:00

    你也可以让moment.js决定什么应输出本地化格式:

      var s = m.format(llll); //Thu,15 Aug 2013 19:00




总结一下 - 如果您只想转换到当地时区(可能是任何区域),那么您可以使用 Date 。 Moment.js将使解析和格式化变得更容易,但并不是绝对必需的。



只有少数需要的场景时区图书馆(如时区或其他地区)。




  • 您要转换为

  • em>从那时起,时区规则或夏令时规则发生了变化,因此,您的日期会根据新规则而不同于旧规则。这有点技术性,但它确实发生。阅读更多此处这里



Let's say user in CA, US picks up a date, time and timezone:

Worldwide beer marathon starts on 8/15/2013 10:00 am, UTC-08:00

Another user, in Central Europe opens the page where this date and time is displayed. He doesn't want to do time calculations (had few beers already). He just wants to see this date and time:

8/15/2013 19:00

Given the browser receives the date and time information, as entered by user in California:

Is there a way, in javascript, without external web services, to do a correct conversion? That is, to detect that 10am UTC-08:00 should actually be 10am UTC-07:00, since it is Daylight Saving.

Maybe I got wrong understanding of this from the beginning, but I don't want to let the entering user to think whether he should choose UTC-08:00 (PST) or UTC-07:00 (PDT). I assume that since the standard timezone in CA is PST, people don't switch to thinking in PDT in summer time. Or do they?!

In central Europe, standard date is UTC+01:00, Daylight Saving date is UTC+02:00. So that difference between CA and Europe should be 9 hours, except for two periods in a year, when one or the other area switches between Standard and Daylight Saving modes.

Update:

After some more thinking and reading the comments, what I would ideally need is this:

var utcOffset = f('2013-08-15T10:00', 'America/Los_Angeles');
// utcOffset == "-07:00"
var utcOffset = f('2013-11-15T10:00', 'America/Los_Angeles');
// utcOffset == "-08:00"

So far, it looks like the moment.js/timezone plugin, suggested by Guido Preite is capable of doing this (more or less).

Any other way, using browser APIs?

解决方案

Is there a way, in javascript, without external web services, to do a correct conversion? That is, to detect that 10am UTC-08:00 should actually be 10am UTC-07:00, since it is Daylight Saving.

10:00-8 and 10:00-7 are two different moments in time. They are equal to 18:00Z and 17:00Z respectively (Z = UTC). When you are measuring in terms of an offset, daylight saving time does not enter the picture. Ever.

I assume that since the standard timezone in CA is PST, people don't switch to thinking in PDT in summer time. Or do they?!

In general, people just think in "Pacific Time", and that means both PST in the winter, and PDT in the summer. But computers are more precise. When you see PST, it means UTC-8. When you see PDT, it means UTC-7. It would be invalid to label using one form while simultaneously referring to the offset of the other.

Time zone abbreviations can be ambiguous. Ideally, when referencing the zone programmatically, you should use the IANA zone name, such as America/Los_Angeles. However, this is not currently possible in all JavaScript runtimes without a library. (They are working on this though.)

In central Europe, standard date is UTC+01:00, Daylight Saving date is UTC+02:00. So that difference between CA and Europe should be 9 hours, except for two periods in a year, when one or the other area switches between Standard and Daylight Saving modes.

Correct. They could be either 8, 9, or 10 hours apart. They switch at completely different times though, so don't try to manage this yourself.

So far, it looks like the moment.js/timezone plugin, suggested by Guido Preite is capable of doing this (more or less).

Moment-timezone is a great library. However, from the scenario you described, I don't think you need to worry about time zone conversion as much as you are thinking. See if you can follow this logic:

  1. The user in California enters a date and time into a textbox.
  2. You read that textbox value into a string, and parse it into a date:

    var dt = new Date("8/15/2013 10:00");
    

    or using moment.js:

    var m = moment("8/15/2013 10:00", "M/D/YYYY HH:mm");
    

  3. Because this is being done on the user's computer, JavaScript will automatically assume that this is a local date and time. You do not need to provide any offset or time zone information.

  4. This does mean that because of the DST transitions that the time entered might be invalid or ambiguous. JavaScript doesn't do such a great job at handling that, in fact - you will get different results on different browsers. If you want to be unambiguous, then you would provide an offset.

    // PST
    var dt = new Date("3/11/2013 1:00 UTC-08:00");
    
    // PDT
    var dt = new Date("3/11/2013 1:00 UTC-07:00");
    

  5. Once you have a Date (or a moment), then you can evaluate its UTC equivalent:

    var s = dt.toISOString();  //  2013-08-15T17:00:00Z
    

    it's the same with moment.js, but you will have better browser support:

    var s = m.toISOString();  //  2013-08-15T17:00:00Z
    

  6. You store that UTC value in your database.

  7. The other user in Central Europe comes along and loads the data.

  8. You feed it in to a Date or moment in JavaScript:

    var dt = new Date("2013-08-15T17:00:00Z");
    

    or with moment.js (again, better browser support)

    var m = moment("2013-08-15T17:00:00Z")
    

  9. Because JavaScript knows the time zone rules of the local computer, you can now display this date and it will be presented with the Central Europe time zone:

    var s = dt.ToString();  //  browser specific output
    // ex: "Thu Aug 15 2013 19:00:00 GMT+0200 (Central Europe Daylight Time)"
    

    or with moment.js, you can control the output format better

    var s = m.format("DD/MM/YYYY HH:mm"); // "15/08/2013 19:00"
    

    you could also let moment.js decide what localized format should be output:

    var s = m.format("llll"); // "Thu, 15 Aug 2013 19:00"
    

To summarize - if you are only interested in converting to and from the local time zone (whatever zone that may be), then you can do it all with just Date. Moment.js will make things easier for parsing and formatting, but it isn't absolutely required.

There are only a few scenarios that require a time zone library (such as moment-timezone or others).

  • You want to convert to or from a zone that is not the local time zone or UTC.

  • You are working with dates that are in the past, and there has been a change to the time zone rules or daylight saving time rules since then, and you have dates that would be interpreted differently under the new rules than with the old ones. This is a bit technical, but it does happen. Read more here and here.

这篇关于如何在时区之间正确转换时间?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆