2012-05-31 33 views
72

Tôi đang tìm kiếm sự hiểu biết tốt hơn về câu chuyện của người dùng sau:Làm cách nào để xử lý các múi giờ trong ứng dụng web của tôi?

John làm việc ở Sidney. Lúc 9 giờ sáng, anh ta ghi lại một sự kiện trong một ứng dụng web chạy trên một máy chủ ở Zurich. Ngày hôm sau, anh đến New York để tham dự một cuộc họp khẩn cấp, trong đó sự kiện nên được thảo luận. Trong cuộc họp, anh ấy tìm kiếm sự kiện theo ngày giờ.

Như tôi đã nhìn thấy nó, có ít nhất hai vấn đề ở đây:

  1. Làm thế nào tôi nên lưu các tem thời gian trong cơ sở dữ liệu
  2. Làm thế nào tôi nên trình bày chúng trong UI

Khi John tìm kiếm sự kiện, anh ta sẽ biết rằng nó đã xảy ra lúc 9:00 nhưng anh ta nên nhập gì vào trình duyệt web? Anh ta sẽ không tìm thấy bất cứ điều gì khi anh ta bước vào "9:00" làm dấu thời gian vì đó có thể là thời gian của Zurich hoặc New York (vì sự kiện này không được tìm thấy, ứng dụng không có cách nào để biết rằng nó đã xảy ra ở Sidney, vì vậy nó không thể tự động chọn múi giờ chính xác).

Cách tốt nhất để hỏi người dùng về dấu thời gian có thể bao gồm múi giờ là gì?

Vấn đề thứ hai là cách hiển thị kết quả. Nếu các đội từ khắp nơi trên thế giới cần thảo luận về sự kiện (và tìm các sự kiện liên quan, hãy nghĩ đến một cuộc tấn công cracker nhắm vào một số trang web trên toàn cầu cùng một lúc).

Ví dụ tốt để hiển thị dấu thời gian có thể đã được tạo trong múi giờ khác là gì?

Lưu ý: Vui lòng tập trung vào khả năng sử dụng của yêu cầu. Tôi có thể tìm ra bản đồ cơ sở dữ liệu bản thân mình. Hiện tại, tôi không chắc chắn về luồng công việc. Nó nên hỏi/trình bày các thông tin cần thiết theo cách không xâm nhập/trực quan. Nếu bạn có thể, hãy cung cấp liên kết tới ứng dụng web hiện có đã giải quyết vấn đề này.

+4

Stack Overflow giải quyết vấn đề này bằng cách đặt mọi thứ vào UTC. Không phải lúc nào cũng thuận tiện, nhưng nó rõ ràng không rõ ràng, không khó thực hiện và hoạt động. – Ryan

+1

UTC là hấp dẫn nhưng OTOH, SO không bao giờ cần phải đồng bộ hóa các sự kiện qua một số múi giờ. –

+0

Nếu bạn di chuột qua thời gian bên cạnh nhận xét, bạn sẽ thấy luồng xếp chồng lưu trữ đã đến lúc trong múi giờ "Zulu". Tôi tự hỏi nếu họ sử dụng nó để nói "Đề cử cho người điều hành cộng đồng kết thúc lúc 8 giờ chiều ngày 19 tháng 6" và họ sử dụng múi giờ để cho phép mọi người trong các múi giờ khác nhau bỏ phiếu cho đến 8 PM tương ứng của họ? –

Trả lời

67

Vấn đề lưu trữ dấu thời gian rất đơn giản: Lưu trữ chúng trong UTC.

Để hiển thị chúng, bạn nên đặt cài đặt múi giờ của thiết bị và sử dụng cài đặt đó làm múi giờ hiện tại. Điều đó nói rằng, sẽ có một danh sách thả xuống múi giờ bên cạnh hộp "thời gian đầu vào", mặc định là múi giờ hiện tại của thiết bị, vì vậy người dùng có thể thay đổi múi giờ nếu cần.

Phần lớn người dùng của bạn có thể sẽ không thay đổi múi giờ nhiều hoặc hoàn toàn. Đối với hầu hết các phần, tình hình bạn vạch ra là không phổ biến. Bằng cách thực hiện một dropdown với một mặc định phù hợp, bạn sẽ có thể làm cho mọi thứ dễ dàng đủ cho những người di chuyển xung quanh (bởi vì họ thường có một sự hiểu biết tốt hơn về múi giờ hơn so với một khách du lịch không).

Thực tế, tốt hơn hết là tiết kiệm múi giờ mà thiết bị được đặt thành khi ứng dụng của bạn được chạy lần đầu tiên và sau đó xem liệu thiết bị có thay đổi hay không. Nếu nó thay đổi, thì người dùng có lẽ là một khách du lịch và có lẽ sẽ được hưởng lợi từ việc thả xuống múi giờ. Nếu không, chỉ không hiển thị menu thả xuống và mặc định theo múi giờ của thiết bị (vì người dùng không cần phải biết về chúng). Trong cả hai trường hợp, có cài đặt trong ứng dụng cho phép người dùng tự hiển thị/ẩn menu thả xuống múi giờ.


Để tóm tắt ở trên:

  • On chạy đầu tiên, tiết kiệm những gì múi giờ thiết bị được thiết lập để.
  • Sử dụng múi giờ đó làm múi giờ mặc định. Luôn luôn giả định múi giờ đó.
  • Nếu thiết bị chuyển múi giờ, hãy thêm trình đơn thả xuống để chọn múi giờ của sự kiện, mặc định theo múi giờ riêng của thiết bị.
  • Thêm tùy chọn để hiển thị/ẩn danh sách thả xuống múi giờ này theo cách thủ công.
  • Luôn lưu trữ dấu thời gian trong UTC.
+0

Chúng tôi có ý nghĩa gì bởi "múi giờ" Có vẻ như được sử dụng không rõ ràng. Điều này có vẻ giống như một tham chiếu: https://en.wikipedia.org/wiki/Tz_database Từ những gì tôi có thể nói "múi giờ" là "Khu vực/Vị trí", ví dụ: "America/New_York". Đó dường như là địa lý tuyệt vời vì ví dụ: America/Los_Angeles có nghĩa là cả PST và PDT tùy thuộc vào việc địa cầu có hoạt động trong Giờ Tiết kiệm Ánh sáng ban ngày hay không. Và nếu đó là trường hợp, câu hỏi đặt ra là làm cách nào để chúng tôi tính toán các thay đổi hai năm một lần trong bù trừ UTC cho các khu vực? Ngoài ra, chúng tôi gọi những ứng dụng này là gì vì chúng không phải là "khu vực" về mặt địa lý? – iJames

8

Trong các ứng dụng của chúng tôi, chúng tôi thường lưu trữ các múi giờ của người sử dụng khi chúng ta đăng ký đầu tiên, như thường thấy trên các trang web diễn đàn, và luôn hiển thị thời gian với múi giờ.

Để lưu trữ ngày, UTC là cách để đi. Chuyển đổi sang UTC và dán nó vào cơ sở dữ liệu. Trong khi truy xuất, chỉ cần chuyển đổi thời gian thành bộ múi giờ cho người dùng.

Tôi đã phải giải quyết một trường hợp sử dụng tương tự, nơi thông báo tùy chỉnh, như "Chúc mừng năm mới", có thể được gửi tới tất cả người dùng ứng dụng web. Vì người dùng được trải rộng trên toàn thế giới, chúng tôi cần hiển thị thông báo theo múi giờ. Lưu trữ dấu thời gian trong UTC độc đáo phục vụ mục đích của chúng tôi, mà không có trục trặc.

Trong trường hợp sử dụng của bạn, nếu bạn không lưu trữ múi giờ của người dùng ở đâu đó, bạn sẽ không bao giờ có thể trả lại chính xác kết quả tìm kiếm của mình mà không yêu cầu đầu vào của người dùng, trừ khi bạn bắt đầu sử dụng một số loại dò tìm vị trí như gmaps, nhưng điều đó không đáng tin cậy. Vì vậy, bạn sẽ cần phải yêu cầu múi giờ mỗi lần để đảm bảo người dùng biết những gì anh ta đang nhập vào trang web.

Nếu bạn có thông tin múi giờ, toàn bộ ứng dụng web sẽ được chạy với cài đặt múi giờ. Do đó khi người dùng tìm kiếm 9:00, anh ta sẽ tìm kiếm theo múi giờ Sydney. Mặt khác, nếu anh ta tạo ra một sự kiện khi đang ngồi ở New York, anh ta sẽ tạo ra một sự kiện với múi giờ Sydney. Chúng tôi giải quyết các trường hợp như vậy bằng cách luôn hiển thị múi giờ trong khi hiển thị ngày.

Hy vọng điều đó sẽ hữu ích! :)

+0

Tôi nghĩ rằng với việc bổ sung một dropdown cho múi giờ khi tìm kiếm và tạo sự kiện, đây là con đường để đi. (khi tôi cần tìm kiếm sự kiện được tạo bởi đồng nghiệp ở New York, tôi không muốn tự mình làm toán) – RasmusWL

1

Đối với trường hợp cụ thể đó, tôi sẽ lưu trữ cả hai số địa phương và UTC. UTC là một phần lớn và được sử dụng để đồng bộ và chuyển đổi thời gian thành múi giờ hiện tại. Địa phương được sử dụng cho các tìm kiếm và để biết bổ sung, như:

Bạn có một cuộc họp:

12:00 Monday (UTC) 
9:00 Monday (Sydney, creation local time) 
11:00 Monday (Zurich, local time) 

hoặc một cái gì đó như thế. Cách khác là lưu trữ múi giờ tạo và chuyển đổi khi chạy (điều này đặc biệt tốt hơn trong trường hợp người dùng sẽ thay đổi thời gian họp). Dù bằng cách nào thì lý do chính là có thể khôi phục thời gian tạo ban đầu để người dùng có thể tham khảo.

1
  1. Làm thế nào tôi nên lưu các tem thời gian trong cơ sở dữ liệu

Tại tạo sự kiện, tôi sẽ lưu trữ UTC thời gian và múi giờ địa phương (aka creation time zone).Tôi sẽ sử dụng những gì tôi được lưu trữ để chuyển đổi thời gian tính theo giờ UTC vào giờ địa phương (aka creation time) và lưu nó cùng với thời gian UTC và creation time zone.

Chú ý: Tôi có thể lưu trữ theo giờ địa phương ngay từ đầu đi, nhưng khi người dùng thực hiện tìm kiếm một sự kiện, tôi sẽ hy vọng một sự chuyển đổi thành giờ cục bộ tồn tại. Tôi cũng hy vọng các máy chủ có thể phát hiện mà múi giờ khách hàng là trong.

  1. Làm thế nào tôi nên trình bày chúng trong UI

Khi người dùng tìm kiếm "09:00", tôi sẽ tìm kiếm sự kiện bao gồm "09:00" trong cả hai UTC hOẶCcreation timehOẶC giờ địa phương. Để có kết quả, tôi sẽ hiển thị một bảng kết quả trong creation time (này được thiết kế để hiển thị timestamps có thể đã được tạo ra trong một múi giờ khác nhau, như chúng ta giả định người dùng đang tìm kiếm những gì thời gian ông đã tạo ra một sự kiện cho bất cứ nơi nào ông.), và hiển thị một bảng kết quả thứ hai bên dưới với kết quả liên quan, có lẽ với tiêu đề, "Không phải những gì bạn đang tìm kiếm? Xem kết quả liên quan" (bao gồm UTC còn lại và kết quả thời gian địa phương).

Nói chung, tôi sẽ hiển thị thời gian UTC, giờ địa phương, creation timecreation time zone (tức là giờ địa phương và múi giờ của sự kiện được tạo) được sắp xếp theo thời gian UTC, để bạn có thể xem sự kiện nào đến đầu tiên, trong trường hợp hai sự kiện khác nhau được lên lịch 9:00 trong hai múi giờ khác nhau.

+1

+1 Tôi thích ý tưởng hiển thị tất cả các sự kiện trong tất cả các múi giờ nơi giờ địa phương khớp; Tôi chỉ không hài lòng với điều kiện SQL (các điều kiện của 'BETWEEN'). –

7

Ở đây tôi đưa ra gợi ý cho khả năng sử dụng tốt nhất mà không làm phiền nhiều về thực hiện khả thi.
1. Đối với vấn đề lưu trữ sự kiện đầu tiên trong db, mọi người sẽ đồng ý lưu trữ sự kiện trong UTC

2. Để mang lại trải nghiệm người dùng tốt nhất, hãy lưu lịch sử múi giờ của người dùng. Nếu bạn có thể lưu dấu thời gian của sự thay đổi múi giờ, thậm chí tốt hơn. Điều này sẽ cho phép chúng tôi cung cấp cho người dùng quyền tự do truy vấn mà không chỉ định rõ múi giờ mỗi lần.

Vì vậy, với các tính năng này, chúng ta hãy xem làm thế nào truy vấn tìm kiếm chỉ "9.00" bởi John sẽ được xử lý:
Với những tính năng nêu trên, bây giờ tôi biết rằng John đã được trong 2 múi giờ cho đến ngày (hoặc lấy danh sách múi giờ cho thời gian được đề cập). Vì vậy, tôi sẽ bí mật 9,00 từ múi giờ Sydney sang UTC, kích hoạt truy vấn. Cũng chuyển đổi 9.00 từ múi giờ NewYork sang UTC, kích hoạt truy vấn . Trong kết quả, tôi sẽ hiển thị 2 hàng để John hiển thị những gì ông đã làm tại 9.00 trong sydney và lúc 9 giờ 9 ở new york. Dòng mới york sẽ trống trong trường hợp này, nhưng tôi nghĩ vẫn nên được hiển thị cho người dùng, chỉ để thông báo cho rằng chúng tôi cũng đã tìm kiếm múi giờ này.

3. Cách tốt nhất để hỏi người dùng về dấu thời gian có thể bao gồm múi giờ là gì?

Nếu múi giờ của mình thời gian gần đây đang thay đổi, bất cứ khi nào anh ta đăng nhập vào ứng dụng, thông báo nên cho rằng, múi giờ mặc định của bạn được thay đổi múi giờ mẹ đẻ.
Trong khi tạo sự kiện, cho phép nói dùng chọn múi giờ từ down.Lets thả không gánh nặng người sử dụng bằng cách đưa ra lựa chọn của tất cả các múi giờ trên thế giới.Tùy chọn thả xuống đầu tiên phải là thời gian hiện tại của khu vực thiết bị của người dùng là . sau khoảng thời gian đó từ lịch sử của mình là múi giờ, sau đó là UTC và sau đó giữ lại múi giờ mà anh chưa bao giờ sử dụng đến ngày .

4.How để hiển thị các kết quả, nếu đội đến từ khắp nơi trên thế giới cần phải thảo luận về sự kiện này:

Tôi muốn chia trường hợp sử dụng này giữa số lượng các đội 2 hoặc nhiều hơn 2.
Chỉ với 2 đội, tôi muốn mỗi đội thấy dấu thời gian theo múi giờ địa phương và múi giờ của nhóm khác. (I cá nhân muốn nói chuyện trong múi giờ của người ở đầu kia cho sự tiện lợi của mình trong khi lên lịch cuộc họp). Đối với nhiều hơn 2 đội, tốt hơn để xem xét múi giờ phổ biến hơn, tức là UTC. Vì vậy, trong trường hợp này, mọi người dùng sẽ thấy dấu thời gian trong 2 múi giờ, ở UTC và trong múi giờ mặc định của anh ấy.

Đề xuất này được đưa ra với ý định rằng người dùng không cần thực hiện bất kỳ phép tính nào theo giờ địa phương của mình, nhưng cũng có thể giao tiếp với người dùng khác một cách trôi chảy trong múi giờ ưa thích của họ.

+2

+1 Đây là một ý tưởng rất thú vị vì tôi biết rằng người dùng đã nhập sự kiện vào lúc 9:00 ở Sidney, vì vậy khi cùng một người dùng tìm kiếm một thời gian (không có múi giờ rõ ràng), tôi giả sử anh ấy có nghĩa là "tôi đã ở đâu tại thời điểm đó " –

9
  1. UTC. Giữ nó đơn giản.

  2. Sử dụng múi giờ có liên quan nhất với người dùng.

    Nếu bạn biết người dùng sẽ đến hoặc đi du lịch đến Sydney cho sự kiện, họ sẽ là suy nghĩ trong múi giờ đó khi sắp xếp phương tiện đến sự kiện. Thực tế là họ hiện đang ở New York phần lớn là không liên quan. Và tất nhiên, nếu ứng dụng của bạn hiển thị ngày trong nhiều múi giờ khác nhau, nó sẽ luôn hiển thị múi giờ bên cạnh ngày, ví dụ: 09:00 EST.

    Nếu nó không làm lộn xộn giao diện của bạn quá nhiều, bạn có thể hiển thị ngày trong múi giờ sự kiện và múi giờ địa phương, ví dụ: 2012-06-13 09:00 EST (2012-06-12 19:00 EDT).

    Tôi cho rằng việc tìm kiếm là một vấn đề tương tự, với một cảnh báo: chúng ta có thể chấp nhận các kết quả sai (nhận được kết quả mà chúng ta không mong đợi), nhưng chúng ta không thể chịu được các âm bản sai (không nhận được kết quả mong đợi)).

    Một lần nữa, tôi tập trung tìm kiếm múi giờ phù hợp nhất cho người dùng (ví dụ múi giờ sự kiện) và ưu tiên các kết quả này trong kết quả tìm kiếm, nhưng bạn cũng có thể trả về các sự kiện phù hợp với các múi giờ khác có liên quan đến người dùng (ví dụ: giờ địa phương). Nếu bạn làm điều này, bạn nên hiển thị ngày sự kiện trong múi giờ phù hợp, đặc biệt nếu bạn đánh dấu văn bản phù hợp.

4

Ok Tôi có một cách tiếp cận khác nhau hơn những người khác:

Thứ nhất, tôi cho rằng vài điều trước khi tay.

người được liệt kê một sự kiện có điện thoại thông minh (nếu nó là một trình duyệt, tôi không cần phải làm cho các giả định) với:

  1. GPS

  2. khả năng HTML5.

  3. Javascript khả năng

Làm thế nào tôi nên lưu các tem thời gian trong cơ sở dữ liệu?

Giải pháp: Rõ ràng UTC, tôi phủ lên thủ tục dưới đây:

Bước 1. Sử dụng Định vị của người sử dụng bằng cách sử dụng API Định vị

window.onload = getMyLocation; 

    function getMyLocation() { 
     if (navigator.geolocation) { 
      navigator.geolocation.getCurrentPosition(displayLocation); 
     } else { 
      alert("Oops, no geolocation support"); 
     } 
    } 

    function displayLocation(position) { 
     var latitude = position.coords.latitude; 
     var longitude = position.coords.longitude; 
     var div = document.getElementById("location"); 
     div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude; 
    } 

Bước 2. Cung cấp cho (Long, Lat) như tranh luận với một số (Lat, Long) đến TimeZone api giống như Yahoo API (sử dụng Cờ R để chuyển đổi Latitude thành Timezon e) để nhận múi giờ của người dùng.

=>Người sử dụng múi giờ được xác định mà không cần người dùng nhập vào (Tôi đang sử dụng này bởi vì bạn không thể chỉ đơn giản là giả định người dùng hiểu biết múi giờ của nơi ông sống trong, tôi biết múi giờ của tôi chỉ sau vài tháng hoặc một cái gì đó ở nơi này : P, khá ngớ ngẩn)

Các tổ chức sự kiện mỗi bảng có Timezone, Event & như vậy cũng có thể có CityName Sau đó tạo một bảng cơ sở dữ liệu với phân loại dựa trên CityName s. Vì vậy, đây người dùng sẽ có hai cột

|---------------------------------------| 
|_____NewYork________|______Sydney______| 
|     |     | 
|Event 1    | Event 2   | 
|____________________|__________________| 

Đối với giao diện người dùng

=> sử dụng Google Calendar API hoặc một số các API Lịch của

Bài đọc liên quan:

  1. Determine timezone from latitude/longitude without using web services like Geonames.org

  2. Timezone lookup from latitude longitude

Tôi biết nó chỉ là về hiển thị một số ý tưởng làm thế nào để giải quyết vấn đề này. Nhưng xem cách chính xác & trọng lượng nhẹ sẽ trở thành người dùng khi Múi giờ được xác định bằng cách sử dụng API thiết bị

Hy vọng điều đó sẽ hữu ích!

+2

Thật dễ dàng để tìm múi giờ của ai đó mà không cần định vị địa lý. 'new Date(). getTimezoneOffset()' cho nó trong vài phút sau UTC. – Ryan

+0

@minitech, đó là sự thật nhưng nếu sự kiện xảy ra ở NewYork và một nơi nào đó ở miền Nam có cùng múi giờ của nó. Tôi đang sử dụng vị trí địa lý để bạn có thể xác định thành phố (thậm chí chính xác), múi giờ trong oneshot & cơ sở bảng db của tôi trên đó. Tôi muốn giảm thiểu đầu vào của người dùng bằng cách sử dụng ** device api ** để tăng hiệu quả của ứng dụng. – uday

+0

Vì vậy? Thời gian sẽ giống nhau ở cả hai nơi, vì vậy không có vấn đề gì. -1 – Ryan

Các vấn đề liên quan