javascript - How to convert time correctly across timezones? -

let's user in ca, picks date, time , timezone:

worldwide beer marathon starts on 8/15/2013 10:00 am, utc-08:00

another user, in central europe opens page date , time displayed. doesn't want time calculations (had few beers already). wants see date , time:

8/15/2013 19:00

given browser receives date , time information, entered user in california:

is there way, in javascript, without external web services, correct conversion? is, detect 10am utc-08:00 should 10am utc-07:00, since daylight saving.

maybe got wrong understanding of beginning, don't want let entering user think whether should choose utc-08:00 (pst) or utc-07:00 (pdt). assume since standard timezone in ca pst, people don't switch thinking in pdt in summer time. or they?!

in central europe, standard date utc+01:00, daylight saving date utc+02:00. difference between ca , europe should 9 hours, except 2 periods in year, when 1 or other area switches between standard , daylight saving modes.

update:

after more thinking , reading comments, ideally need 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, looks moment.js/timezone plugin, suggested guido preite capable of doing (more or less).

any other way, using browser apis?

is there way, in javascript, without external web services, correct conversion? is, detect 10am utc-08:00 should 10am utc-07:00, since daylight saving.

10:00-8 , 10:00-7 2 different moments in time. equal 18:00z , 17:00z respectively (z = utc). when measuring in terms of offset, daylight saving time not enter picture. ever.

i assume since standard timezone in ca pst, people don't switch thinking in pdt in summer time. or they?!

in general, people think in "pacific time", , means both pst in winter, , pdt in summer. computers more precise. when see pst, means utc-8. when see pdt, means utc-7. invalid label using 1 form while simultaneously referring offset of other.

time zone abbreviations can ambiguous. ideally, when referencing zone programmatically, should use iana zone name, such america/los_angeles. however, not possible in javascript runtimes without library. (they working on though.)

in central europe, standard date utc+01:00, daylight saving date utc+02:00. difference between ca , europe should 9 hours, except 2 periods in year, when 1 or other area switches between standard , daylight saving modes.

correct. either 8, 9, or 10 hours apart. switch @ different times though, don't try manage yourself.

so far, looks moment.js/timezone plugin, suggested guido preite capable of doing (more or less).

moment-timezone great library. however, scenario described, don't think need worry time zone conversion as thinking. see if can follow logic:

1. the user in california enters date , time textbox.

2. you read textbox value string, , parse 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 being done on user's computer, javascript automatically assume local date , time. not need provide offset or time zone information.

4. this mean because of dst transitions time entered might invalid or ambiguous. javascript doesn't such great job @ handling that, in fact - different results on different browsers. if want unambiguous, provide 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 have date (or moment), can evaluate utc equivalent:

   var s = dt.toisostring();  //  2013-08-15t17:00:00z 

   it's same moment.js, have better browser support:

   var s = m.toisostring();  //  2013-08-15t17:00:00z 

6. you store utc value in database.

7. the other user in central europe comes along , loads data.

8. you feed in date or moment in javascript:

   var dt = new date("2013-08-15t17:00:00z"); 

   or moment.js (again, better browser support)

   var m = moment("2013-08-15t17:00:00z") 

9. because javascript knows time zone rules of local computer, can display date , presented 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 moment.js, can control output format better

   var s = m.format("dd/mm/yyyy hh:mm"); // "15/08/2013 19:00" 

   you let moment.js decide localized format should output:

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

to summarize - if interested in converting , local time zone (whatever zone may be), can date. moment.js make things easier parsing , formatting, isn't absolutely required.

there few scenarios require time zone library (such moment-timezone or others).

• you want convert or zone not local time zone or utc.

• you working dates in past, and there has been change time zone rules or daylight saving time rules since then, and have dates interpreted differently under new rules old ones. bit technical, happen. read more here , here.