全球啤酒马拉松赛开始于8/15/2013 10:00 UTC,UTC-08：00
在中欧的另一个用户打开显示此日期和时间的页面.他不想做时间计算(已经很少的啤酒).他只是希望看到这个日期和时间：
8/15/2013 19:00
鉴于浏览器收到日期和时间信息,由加利福尼亚州的用户输入：
有没有办法,在javascript中,没有外部Web服务,要做正确的转换？也就是说,为了检测UTC-08：00的上午10点应该是UTC-07：00的10点,因为它是夏令时.
也许我从一开始就误解了这一点,但是我不想让输入的用户考虑他是否应该选择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？
解决方法
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和10：00-7是两个不同的时刻.它们分别等于18：00Z和17：00Z(Z = UTC).当您使用偏移量进行测量时,夏令时不会进入图像.永远.
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?!
一般来说,人们只是想在“太平洋时间”,这意味着PST在冬天和PDT在夏天.但电脑更精确.当你看到PST,这意味着UTC-8.当你看到PDT,这意味着UTC-7.使用一个表单标签时同时引用另一个表单的偏移将无效.
时区缩写can be ambiguous.理想情况下,当以编程方式引用区域时,应使用IANA区域名称,例如America / Los_Angeles.但是,在没有库的所有JavaScript运行时中,目前都不可能. (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.
正确.它们可以是8,9或10小时.他们切换完全不同,所以不要试图自己管理.
So far,it looks like the moment.js/timezone plugin,suggested by Guido Preite is capable of doing this (more or less).
Moment-timezone是一个很棒的图书馆.但是,从您描述的场景中,我不认为您需要担心时区转换与您正在考虑的那样多.看看你可以遵循这个逻辑：
>加利福尼亚州的用户将日期和时间输入到一个文本框中.
>您将该文本框值读入字符串,并将其解析为日期：
var dt = new Date("8/15/2013 10:00");
或使用moment.js：
var m = moment("8/15/2013 10:00","M/D/YYYY HH:mm");
>因为这是在用户的计算机上完成的,JavaScript会自动假定这是一个本地的日期和时间.您不需要提供任何偏移量或时区信息.
>这意味着由于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");
>一旦你有一个日期(或一时),那么你可以评估它的UTC等效值：
var s = dt.toISOString(); // 2013-08-15T17:00:00Z
它与moment.js是一样的,但你会有更好的浏览器支持：
var s = m.toISOString(); // 2013-08-15T17:00:00Z
>将您的UTC值存储在数据库中.
>中欧的另一位用户正在加载数据.
>您可以将其输入到JavaScript的日期或时刻：
var dt = new Date("2013-08-15T17:00:00Z");
或使用moment.js(再次,更好的浏览器支持)
var m = moment("2013-08-15T17:00:00Z")
>因为JavaScript知道本地计算机的时区规则,您现在可以显示此日期,并显示中欧时区：
var s = dt.ToString(); // browser specific output // ex: "Thu Aug 15 2013 19:00:00 GMT+0200 (Central Europe Daylight Time)"
或者使用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将使解析和格式化变得更加容易,但并不是绝对必需的.
只有少数场景需要时区库(如时区或其他).
>您要转换为或不是本地时区或UTC的区域.
>您正在处理过去的日期,自那以后,时区规则或夏令时规则发生了变化,并且您的日期将根据新规则与旧规则不同地进行解释.这有点技术性,但它确实发生.阅读更多here和here.
