2012-05-07 42 views
9

Tài liệu cho Date.getTimezoneOffset nói:Tại sao Date.getTimezoneOffset không được chấp nhận?

Không được chấp nhận. Kể từ phiên bản JDK 1.1, thay thế bằng - (Lịch.get (Lịch.ZONE_OFFSET) + Lịch.get (Lịch.DST_OFFSET))/(60 * 1000).

Tại sao nó không được dùng nữa? Có cách nào ngắn hơn (Apache Commons?) Để nhận khoản chênh lệch từ UTC theo giờ/phút? Tôi có một đối tượng Date ... tôi có nên chuyển nó sang JodaDate cho việc này không?

Và trước khi bạn hỏi lý do tại sao tôi muốn bù trừ UTC - đó chỉ là để ghi nhật ký, không có gì khác.

+2

Bạn nên chuyển sang JodaTime cho bất kỳ điều gì liên quan đến Xử lý ngày và giờ trong Java IMHO. – pcalcao

+4

Vì không phải mọi khoảng thời gian bù giờ là một số nguyên. Nói cách khác, không phải mọi múi giờ đều sớm hơn một giờ hoặc muộn hơn múi giờ liền kề. Kiểm tra http://www.timeanddate.com/worldclock/ –

+2

@GilbertLeBlanc - nó trả về phút, không phải giờ. – ripper234

Trả lời

10

Có 2 câu hỏi tại đây.

  1. Tại sao Date.getTimezoneKhông được chấp nhận?

Tôi nghĩ rằng đó là bởi vì họ thực sự không dùng gần như tất cả các phương pháp của Ngày và chuyển logic của họ sang lịch. Chúng tôi dự kiến ​​sử dụng chung số setget với thông số cho biết chúng tôi cần trường cụ thể nào. Cách tiếp cận này có một số ưu điểm: số phương pháp ít hơn và khả năng chạy các bộ định tuyến trong một vòng lặp đi qua một trường khác nhau mỗi lần. Cá nhân tôi đã sử dụng kỹ thuật này rất nhiều: nó làm cho mã ngắn hơn và dễ bảo trì hơn.

  1. Phím tắt? Nhưng những gì xảy ra với cuộc gọi

Calendar.get(Calendar.DST_OFFSET) so với Calendar.getTimeZoneOffset()

Theo như tôi có thể thấy sự khác biệt là 6 ký tự.

Joda là một thư viện rất mạnh và nếu bạn thực sự phải viết rất nhiều công cụ xử lý mã phức tạp ngày cho nó. Cá nhân tôi sử dụng tiêu chuẩn java.util.Calendar và không thấy bất kỳ lý do gì để sử dụng thư viện bên ngoài: lịch cũ tốt là đủ tốt đối với tôi.

+1

+1 để giới thiệu Joda. –

+0

Tôi sẽ chấp nhận điều này cho 'họ thực sự đã phản đối tất cả các phương pháp của Ngày '. Mọi người đề nghị tôi chuyển sang joda - vui lòng làm ơn, đó là đối tượng ngày trong API tôi đang sử dụng, tôi thực sự không thể thay đổi API ngay bây giờ, có thể I. – ripper234

3

Tất cả logic thao tác ngày được di chuyển ra khỏi Date khi người triển khai Java nhận ra rằng nó có thể cần phải được triển khai khác nhau cho các loại lịch khác nhau (do đó cần phải sử dụng GregorianCalendar để truy xuất thông tin này ngay bây giờ). A Date hiện chỉ là trình bao bọc xung quanh giá trị thời gian UTC.

2

Hãy cẩn thận trước khi bạn dán mã từ trang này. Có lẽ chỉ có tôi nhưng tôi tin rằng để có được tz bù đắp trong vài phút bạn cần làm

int tzOffsetMin = (cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60); 

hơn là những gì Javadoc nói, đó là:

int tzOffsetMin = -(cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60); 



Calendar.ZONE_OFFSET cung cấp cho bạn các bù đắp tiêu chuẩn (trong msecs) từ UTC. Điều này không thay đổi với DST. Ví dụ cho múi giờ Bờ Đông Hoa Kỳ, trường này sẽ luôn là -6 giờ bất kể DST.

Calendar.DST_OFFSET cung cấp cho bạn khoản bù DST hiện tại (tính bằng msecs) - nếu có.Ví dụ: trong mùa hè ở một quốc gia sử dụng DST trường này có thể có giá trị +1 giờ (1000 * 60 * 60 msec).

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