Làm thế nào để đối phó thanh lịch với múi giờ


140

Tôi có một trang web được lưu trữ ở múi giờ khác với người dùng sử dụng ứng dụng. Ngoài ra, người dùng có thể có múi giờ cụ thể. Tôi đã tự hỏi làm thế nào người dùng và ứng dụng SO khác tiếp cận điều này? Phần rõ ràng nhất là bên trong DB, ngày / giờ được lưu trữ trong UTC. Khi trên máy chủ, tất cả ngày / giờ nên được xử lý trong UTC. Tuy nhiên, tôi thấy ba vấn đề mà tôi đang cố gắng khắc phục:

  1. Lấy thời gian hiện tại trong UTC (giải quyết dễ dàng với DateTime.UtcNow).

  2. Kéo ngày / lần từ cơ sở dữ liệu và hiển thị chúng cho người dùng. Có khả năng rất nhiều cuộc gọi để in ngày trên các chế độ xem khác nhau. Tôi đã suy nghĩ về một số lớp ở giữa chế độ xem và bộ điều khiển có thể giải quyết vấn đề này. Hoặc có một phương thức mở rộng tùy chỉnh trên DateTime(xem bên dưới). Mặt trái chính là ở mọi vị trí sử dụng datetime trong chế độ xem, phương thức mở rộng phải được gọi!

    Điều này cũng sẽ thêm khó khăn để sử dụng một cái gì đó như JsonResult. Bạn không còn có thể dễ dàng gọi Json(myEnumerable), nó sẽ phải được Json(myEnumerable.Select(transformAllDates)). Có lẽ AutoMapper có thể giúp đỡ trong tình huống này?

  3. Nhận đầu vào từ người dùng (Cục bộ đến UTC). Ví dụ: Đăng một biểu mẫu có ngày sẽ yêu cầu chuyển đổi ngày thành UTC trước đó. Điều đầu tiên xuất hiện trong tâm trí là tạo ra một tùy chỉnh ModelBinder.

Đây là các tiện ích mở rộng mà tôi nghĩ sẽ sử dụng trong các chế độ xem:

public static class DateTimeExtensions
{
    public static DateTime UtcToLocal(this DateTime source, 
        TimeZoneInfo localTimeZone)
    {
        return TimeZoneInfo.ConvertTimeFromUtc(source, localTimeZone);
    }

    public static DateTime LocalToUtc(this DateTime source, 
        TimeZoneInfo localTimeZone)
    {
        source = DateTime.SpecifyKind(source, DateTimeKind.Unspecified);
        return TimeZoneInfo.ConvertTimeToUtc(source, localTimeZone);
    }
}

Tôi nghĩ rằng việc xử lý các múi giờ sẽ là một điều phổ biến khi xem xét rất nhiều ứng dụng hiện đang dựa trên đám mây trong đó giờ địa phương của máy chủ có thể khác nhiều so với múi giờ dự kiến.

Điều này đã được giải quyết thanh lịch trước đây? Có điều gì tôi đang thiếu? Ý tưởng và suy nghĩ được nhiều đánh giá cao.

EDIT: Để xóa một số nhầm lẫn tôi nghĩ thêm một số chi tiết. Vấn đề bây giờ không phải là làm thế nào để lưu trữ thời gian UTC trong db, mà là về quá trình đi từ UTC-> Địa phương và Địa phương-> UTC. Như @Max Zerbini chỉ ra, rõ ràng là thông minh khi đặt UTC-> Mã cục bộ trong chế độ xem, nhưng có DateTimeExtensionsthực sự sử dụng câu trả lời không? Khi nhận đầu vào từ người dùng, có nghĩa là chấp nhận ngày là giờ địa phương của người dùng (vì đó là thứ mà JS sẽ sử dụng) và sau đó sử dụng một ModelBinderbiến đổi thành UTC? Múi giờ của người dùng được lưu trữ trong DB và dễ dàng lấy ra.


3
Trước tiên bạn có thể đọc qua bài đăng tuyệt vời này ... Thực hành tiết kiệm thời gian ban ngày và múi giờ tốt nhất
dodgy_coder

@dodgy_coder - Đó luôn là một liên kết tài nguyên tuyệt vời cho các múi giờ. Tuy nhiên, nó không thực sự giải quyết bất kỳ vấn đề nào của tôi (cụ thể liên quan đến MVC). Cảm ơn mặc dù.
TheCloudlessSky


Tò mò bạn đã chọn giải pháp nào. Đối mặt với quyết định tương tự bản thân mình. Câu hỏi hay.
Sean

@Sean - Giải pháp cho đến nay vẫn chưa được thanh lịch (đó là lý do tại sao tôi vẫn chưa chấp nhận câu trả lời). Đó là rất nhiều chi phí thủ công của ngày / lần in và chuyển đổi thủ công lại bằng a ModelBinder.
TheCloudlessSky

Câu trả lời:


106

Không rằng đây là một đề nghị, chia sẻ nhiều hơn nữa của một mô hình, nhưng hầu hết agressive cách tôi đã nhìn thấy năng xử lý thông tin múi giờ trong một ứng dụng web (mà không dành riêng cho ASP.NET MVC) là như sau:

  • Tất cả thời gian ngày trên máy chủ là UTC. Điều đó có nghĩa là sử dụng, như bạn đã nói , DateTime.UtcNow.

  • Cố gắng tin tưởng khách hàng vượt qua ngày đến máy chủ càng ít càng tốt. Ví dụ: nếu bạn cần "ngay bây giờ", đừng tạo một ngày trên máy khách và sau đó chuyển nó đến máy chủ. Tạo một ngày trong GET của bạn và chuyển nó vào ViewModel hoặc trên POST làm DateTime.UtcNow.

Cho đến nay, giá vé khá chuẩn, nhưng đây là nơi mọi thứ trở nên 'thú vị'.

  • Nếu bạn phải chấp nhận một ngày từ khách hàng, thì hãy sử dụng javascript để đảm bảo dữ liệu bạn đang đăng lên máy chủ có trong UTC. Khách hàng biết múi giờ của nó là gì, vì vậy nó có thể với độ chính xác hợp lý chuyển đổi thời gian thành UTC.

  • Khi hiển thị chế độ xem, họ đang sử dụng <time>phần tử HTML5 , họ sẽ không bao giờ kết xuất dữ liệu trực tiếp trong ViewModel. Nó đã được thực hiện như là một HtmlHelperphần mở rộng, một cái gì đó như Html.Time(Model.when). Nó sẽ kết xuất <time datetime='[utctime]' data-date-format='[datetimeformat]'></time>.

    Sau đó, họ sẽ sử dụng javascript để dịch thời gian UTC sang giờ địa phương của khách hàng. Kịch bản sẽ tìm tất cả các <time>phần tử và sử dụng thuộc tính date-formatdữ liệu để định dạng ngày và điền vào nội dung của phần tử.

Bằng cách này, họ không bao giờ phải theo dõi, lưu trữ hoặc quản lý múi giờ của khách hàng. Máy chủ không quan tâm đến múi giờ của máy khách, cũng như không phải thực hiện bất kỳ bản dịch múi giờ nào. Nó chỉ đơn giản là nhổ UTC và để khách hàng chuyển đổi nó thành một cái gì đó hợp lý. Điều này dễ dàng từ trình duyệt, bởi vì nó biết múi giờ của nó là gì. Nếu khách hàng thay đổi múi giờ của mình, ứng dụng web sẽ tự động cập nhật. Thứ duy nhất mà họ lưu trữ là chuỗi định dạng datetime cho miền địa phương của người dùng.

Tôi không nói rằng đó là cách tiếp cận tốt nhất, nhưng đó là một cách khác mà tôi chưa từng thấy trước đây. Có lẽ bạn sẽ lượm lặt được một số ý tưởng thú vị từ nó.


Cám ơn phản hồi của bạn. Khi nhận được ngày đầu vào từ người sử dụng (ví dụ lên lịch cuộc hẹn), chứ không phải là đầu vào này giả định là trong múi giờ hiện tại của họ? Bạn nghĩ gì về ModelBinder khi thực hiện chuyển đổi này trước khi tham gia hành động (xem nhận xét của tôi với @casperOne. Ngoài ra, <time>ý tưởng này khá tuyệt. Nhược điểm duy nhất là tôi cần truy vấn toàn bộ DOM cho các yếu tố này, điều này có nghĩa là tôi cần truy vấn toàn bộ DOM cho các yếu tố này, điều này chính xác là không tốt để chuyển đổi ngày (còn JS bị vô hiệu hóa thì sao?) Cảm ơn một lần nữa!
TheCloudlessSky

Thông thường, có giả định là nó sẽ ở múi giờ địa phương. Nhưng họ đã đưa ra một điểm để đảm bảo rằng bất cứ khi nào họ thu thập được thời gian từ người dùng, nó đã được chuyển đổi thành UTC bằng cách sử dụng javascript trước khi nó được gửi đến máy chủ. Giải pháp của họ rất nặng về JS và đã không xuống cấp rất tốt khi tắt JS. Tôi chưa nghĩ về nó đủ để xem có thông minh nào xung quanh đó không. Nhưng như tôi đã nói có lẽ nó sẽ cho bạn một vài ý tưởng.
J. Holmes

2
Kể từ đó tôi đã làm việc cho một dự án khác cần ngày địa phương và đây là phương pháp mà tôi đã sử dụng. Tôi đang sử dụng khoảnh khắc để thực hiện định dạng ngày / giờ ... thật tuyệt vời. Cảm ơn!
TheCloudlessSky

Không có cách nào đơn giản để xác định trong app.config / web.cofig của ứng dụng một múi giờ phạm vi ứng dụng và làm cho nó biến tất cả các giá trị DateTime. Làm thế nào thành DateTime.UtcNow? (Tôi muốn tránh các tình huống mà các lập trình viên trong công ty vẫn sẽ sử dụng DateTime. Do nhầm lẫn)
Uri Abramson

3
Một nhược điểm của phương pháp này mà tôi có thể thấy là khi bạn đang sử dụng thời gian cho những thứ khác, tạo pdf, email và như vậy, không có yếu tố thời gian cho những thứ đó vì vậy bạn vẫn sẽ phải chuyển đổi chúng theo cách thủ công.
Mặt

15

Sau nhiều phản hồi, đây là giải pháp cuối cùng của tôi mà tôi nghĩ là sạch sẽ và đơn giản và bao gồm các vấn đề tiết kiệm ánh sáng ban ngày.

1 - Chúng tôi xử lý việc chuyển đổi ở cấp độ mô hình. Vì vậy, trong lớp Model, chúng ta viết:

    public class Quote
    {
        ...
        public DateTime DateCreated
        {
            get { return CRM.Global.ToLocalTime(_DateCreated); }
            set { _DateCreated = value.ToUniversalTime(); }
        }
        private DateTime _DateCreated { get; set; }
        ...
    }

2 - Trong trình trợ giúp toàn cầu, chúng tôi thực hiện chức năng tùy chỉnh "ToLocalTime":

    public static DateTime ToLocalTime(DateTime utcDate)
    {
        var localTimeZoneId = "China Standard Time";
        var localTimeZone = TimeZoneInfo.FindSystemTimeZoneById(localTimeZoneId);
        var localTime = TimeZoneInfo.ConvertTimeFromUtc(utcDate, localTimeZone);
        return localTime;
    }

3 - Chúng tôi có thể cải thiện điều này hơn nữa, bằng cách lưu id múi giờ trong mỗi hồ sơ Người dùng để chúng tôi có thể truy xuất từ ​​lớp người dùng thay vì sử dụng "Giờ chuẩn Trung Quốc" không đổi:

public class Contact
{
    ...
    public string TimeZone { get; set; }
    ...
}

4 - Tại đây chúng tôi có thể lấy danh sách múi giờ để hiển thị cho người dùng chọn từ hộp thả xuống:

public class ListHelper
{
    public IEnumerable<SelectListItem> GetTimeZoneList()
    {
        var list = from tz in TimeZoneInfo.GetSystemTimeZones()
                   select new SelectListItem { Value = tz.Id, Text = tz.DisplayName };

        return list;
    }
}

Vì vậy, bây giờ lúc 9:25 sáng tại Trung Quốc, Trang web được lưu trữ tại Hoa Kỳ, ngày được lưu trong UTC tại cơ sở dữ liệu, đây là kết quả cuối cùng:

5/9/2013 6:25:58 PM (Server - in USA) 
5/10/2013 1:25:58 AM (Database - Converted UTC)
5/10/2013 9:25:58 AM (Local - in China)

BIÊN TẬP

Cảm ơn Matt Johnson đã chỉ ra những phần yếu của giải pháp ban đầu và xin lỗi vì đã xóa bài gốc, nhưng gặp vấn đề với định dạng hiển thị mã đúng ... hóa ra trình soạn thảo có vấn đề trộn "đạn" với "mã trước", vì vậy tôi loại bỏ các khối và nó là ok.


Nó dường như có thể thực hiện được nếu một số người không có kiến ​​trúc n tầng hoặc thư viện Web được chia sẻ. Làm thế nào chúng ta có thể chia sẻ id múi giờ đến lớp dữ liệu.
Vikash Kumar

9

Trong phần sự kiện trên sf4answers , người dùng nhập địa chỉ cho một sự kiện, cũng như ngày bắt đầu và ngày kết thúc tùy chọn. Những lần này được dịch thành mộtdatetimeoffset máy chủ SQL chiếm phần bù từ UTC.

Đây là cùng một vấn đề bạn đang gặp phải (mặc dù bạn đang thực hiện một cách tiếp cận khác với nó, trong đó bạn đang sử dụng DateTime.UtcNow); bạn có một vị trí và bạn cần dịch thời gian từ múi giờ này sang múi giờ khác.

Có hai điều chính tôi đã làm cho tôi. Đầu tiên, sử dụng DateTimeOffsetcấu trúc , luôn luôn. Nó chiếm phần bù từ UTC và nếu bạn có thể lấy thông tin đó từ khách hàng của mình, nó sẽ giúp cuộc sống của bạn dễ dàng hơn một chút.

Thứ hai, khi thực hiện các bản dịch, giả sử bạn biết vị trí / múi giờ mà khách hàng đang ở, bạn có thể sử dụng cơ sở dữ liệu múi giờ thông tin công cộng để dịch thời gian từ UTC sang múi giờ khác (hoặc tam giác, nếu bạn sẽ, giữa hai Múi giờ). Điều tuyệt vời về cơ sở dữ liệu tz (đôi khi được gọi là cơ sở dữ liệu Olson ) là nó chiếm các thay đổi về múi giờ trong suốt lịch sử; nhận được phần bù là một chức năng của ngày mà bạn muốn nhận phần bù (chỉ cần xem Đạo luật chính sách năng lượng năm 2005 đã thay đổi ngày khi thời gian tiết kiệm ánh sáng ban ngày có hiệu lực ở Mỹ ).

Với cơ sở dữ liệu trong tay, bạn có thể sử dụng API .NET của ZoneInfo (cơ sở dữ liệu tz / cơ sở dữ liệu Olson) . Lưu ý rằng không có phân phối nhị phân, bạn sẽ phải tải xuống phiên bản mới nhất và tự biên dịch nó.

Tại thời điểm viết bài này, hiện tại nó phân tích tất cả các tệp trong bản phân phối dữ liệu mới nhất (tôi thực sự đã chạy nó với tệp ftp://elsie.nci.nih.gov/pub/tzdata2011k.tar.gz vào ngày 25 tháng 9, 2011; vào tháng 3 năm 2017, bạn sẽ nhận được nó qua https://iana.org/time-zones hoặc từ ftp://fpt.iana.org/tz/release/tzdata2017a.tar.gz ).

Vì vậy, trên sf4answers, sau khi nhận được địa chỉ, nó được mã hóa thành một tổ hợp vĩ độ / kinh độ và sau đó được gửi đến dịch vụ web của bên thứ ba để lấy múi giờ tương ứng với một mục trong cơ sở dữ liệu tz. Từ đó, thời gian bắt đầu và kết thúc được chuyển đổi thànhDateTimeOffset thể hiện với phần bù UTC thích hợp và sau đó được lưu trữ trong cơ sở dữ liệu.

Đối với việc xử lý nó trên SO và các trang web, nó phụ thuộc vào đối tượng và những gì bạn đang cố gắng hiển thị. Nếu bạn để ý, hầu hết các trang web xã hội (và SO và phần sự kiện trên sf4answers) sẽ hiển thị các sự kiện tương đối thời gian hoặc, nếu sử dụng một giá trị tuyệt đối, đó thường là UTC.

Tuy nhiên, nếu đối tượng của bạn mong đợi giờ địa phương, thì việc sử dụng DateTimeOffsetcùng với một phương thức mở rộng sử dụng múi giờ để chuyển đổi sẽ rất ổn; kiểu dữ liệu SQL datetimeoffsetsẽ dịch sang .NET DateTimeOffsetmà sau đó bạn có thể có được thời gian chung để sử dụng GetUniversalTimephương thức . Từ đó, bạn chỉ cần sử dụng các phương thức trên ZoneInfolớp để chuyển đổi từ UTC sang giờ địa phương (bạn sẽ phải thực hiện một công việc nhỏ để đưa nó vàoDateTimeOffset , nhưng nó đủ đơn giản để làm).

Làm đâu để biến đổi? Đó là một chi phí bạn sẽ phải trả ở đâu đó , và không có cách "tốt nhất". Tuy nhiên, tôi sẽ chọn chế độ xem, với phần bù múi giờ là một phần của mô hình chế độ xem được trình bày cho chế độ xem. Theo cách đó, nếu các yêu cầu cho chế độ xem thay đổi, bạn không phải thay đổi mô hình chế độ xem của mình để phù hợp với thay đổi. Của bạn JsonResultchỉ đơn giản sẽ chứa một mô hình với bù.IEnumerable<T>

Về phía đầu vào, sử dụng một chất kết dính mô hình? Tôi nói hoàn toàn không có cách nào. Bạn không thể đảm bảo rằng tất cả các ngày (hiện tại hoặc trong tương lai) sẽ phải được chuyển đổi theo cách này, đây phải là một chức năng rõ ràng của bộ điều khiển của bạn để thực hiện hành động này. Một lần nữa, nếu các yêu cầu thay đổi, bạn không phải điều chỉnh một hoặc nhiều ModelBindertrường hợp để điều chỉnh logic kinh doanh của mình; và đó logic nghiệp vụ, có nghĩa là nó phải nằm trong bộ điều khiển.


Cảm ơn phản hồi chi tiết của bạn. Tôi hy vọng tôi không gặp phải sự thô lỗ, nhưng điều này thực sự không trả lời bất kỳ mối quan tâm nào của tôi với ASP.NET MVC: Điều gì về đầu vào của người dùng (sử dụng một chất kết dính mô hình tùy chỉnh đủ)? Và quan trọng nhất, còn việc hiển thị những ngày này (theo múi giờ địa phương của người dùng) thì sao? Tôi cảm thấy như phương pháp mở rộng sẽ tăng thêm trọng lượng cho các quan điểm của tôi có vẻ không cần thiết.
TheCloudlessSky

1
@TheCloudlessSky: Xem hai đoạn cuối của phản hồi đã chỉnh sửa của tôi. Cá nhân, tôi nghĩ rằng các chi tiết về nơi để thực hiện các biến đổi là nhỏ; vấn đề chính là chuyển đổi và lưu trữ dữ liệu datetime thực tế (btw, tôi không thể nhấn mạnh đủ việc sử dụng datetimeoffsetSQL Server và DateTimeOffset.NET ở đây, họ thực sự đơn giản hóa mọi thứ rất nhiều) mà tôi tin rằng .NET không xử lý đầy đủ tất cả vì những lý do đã nêu ở trên. Nếu bạn có một ngày ở NYC được nhập vào năm 2003, và sau đó bạn muốn nó được dịch thành một ngày ở LA vào năm 2011, thì .NET đã thất bại trong trường hợp này.
casperOne

Vấn đề với việc không sử dụng chất kết dính mô hình (hoặc bất kỳ lớp nào trước khi hành động) là mọi bộ điều khiển trở nên rất khó kiểm tra khi làm việc với ngày (tất cả đều có được sự phụ thuộc vào chuyển đổi ngày). Điều này sẽ cho phép ngày kiểm tra đơn vị được viết bằng UTC. Ứng dụng của tôi có người dùng được liên kết với một hồ sơ (nghĩ rằng các bác sĩ / thư ký liên quan đến thực hành của họ). Hồ sơ lưu giữ thông tin múi giờ. Do đó, thật dễ dàng để có được múi giờ của người dùng hiện tại và chuyển đổi trong khi ràng buộc. Bạn có lập luận khác chống lại điều này? Cảm ơn vì đầu vào của bạn!
TheCloudlessSky

Trường hợp chống lại điều đó là các xét nghiệm của bạn sẽ không phản ánh chính xác các trường hợp thử nghiệm. Đầu vào của bạn sẽ không ở trong UTC, vì vậy các trường hợp thử nghiệm của bạn không nên được tạo để sử dụng nó. Nó nên sử dụng ngày trong thế giới thực với các địa điểm và tất cả (mặc dù nếu bạn sử dụng, DateTimeOffsetbạn sẽ giảm thiểu điều này rất nhiều, IMO).
casperOne

Có - nhưng điều này có nghĩa là mọi bài kiểm tra liên quan đến ngày phải tính đến điều này. Mọi hành động liên quan đến datetimes sẽ luôn chuyển đổi sang UTC. Đối với tôi đây là một ứng cử viên chính cho chất kết dính mô hình và sau đó kiểm tra chất kết dính mô hình .
TheCloudlessSky

5

Đây chỉ là ý kiến ​​của tôi, tôi nghĩ rằng ứng dụng MVC nên tách biệt vấn đề trình bày dữ liệu khỏi quản lý mô hình dữ liệu. Một cơ sở dữ liệu có thể lưu trữ dữ liệu theo thời gian của máy chủ cục bộ nhưng đó là nhiệm vụ của lớp trình bày để hiển thị datetime bằng múi giờ người dùng cục bộ. Đây dường như là vấn đề tương tự như I18N và định dạng số cho các quốc gia khác nhau. Trong trường hợp của bạn, ứng dụng của bạn sẽ phát hiện Culturevà múi giờ của người dùng và thay đổi Chế độ xem hiển thị văn bản, số và cách trình bày thời gian khác nhau, nhưng dữ liệu được lưu trữ có thể có cùng định dạng.


Cám ơn phản hồi của bạn. Vâng, đây là những gì tôi đã mô tả về cơ bản, tôi chỉ tự hỏi làm thế nào điều này có thể đạt được một cách thanh lịch với MVC. Ứng dụng lưu trữ múi giờ của người dùng như một phần của việc tạo tài khoản của họ (họ chọn múi giờ của họ). Vấn đề một lần nữa đi kèm với cách hiển thị ngày trong mỗi chế độ xem mà không (hy vọng) phải xả rác chúng bằng các phương thức mà tôi đã tạo DateTimeExtensions.
TheCloudlessSky

Có nhiều cách để làm điều này, một là sử dụng các phương thức của trình trợ giúp như bạn đề xuất, một cách khác có lẽ phức tạp hơn nhưng thanh lịch hơn là sử dụng bộ lọc xử lý các yêu cầu và phản hồi và chuyển đổi datetime. Một cách khác là phát triển thuộc tính Hiển thị tùy chỉnh để chú thích các trường loại DateTime của mô hình chế độ xem của bạn.
Massimo Zerbini

Đó là những thứ tôi đang tìm kiếm. Nếu bạn nhìn vào OP của tôi, tôi cũng đã đề cập đến việc sử dụng AutoMapper để thực hiện một số xử lý trước khi đi đến kết quả view / json nhưng sau khi hành động đã được thực thi.
TheCloudlessSky

1

Đối với đầu ra, tạo một mẫu hiển thị / trình soạn thảo như thế này

@inherits System.Web.Mvc.WebViewPage<System.DateTime>
@Html.Label(Model.ToLocalTime().ToLongTimeString()))

Bạn có thể liên kết chúng dựa trên các thuộc tính trên mô hình của bạn nếu bạn chỉ muốn một số mô hình nhất định sử dụng các mẫu đó.

Xem ở đâyở đây để biết thêm chi tiết về việc tạo các mẫu biên tập tùy chỉnh.

Ngoài ra, vì bạn muốn nó hoạt động cho cả đầu vào và đầu ra, tôi sẽ đề nghị mở rộng một điều khiển hoặc thậm chí tạo riêng của bạn. Bằng cách đó bạn có thể chặn cả đầu vào và đầu ra và chuyển đổi văn bản / giá trị nếu cần.

Liên kết này hy vọng sẽ đẩy bạn đi đúng hướng nếu bạn muốn đi theo con đường đó.

Dù bằng cách nào, nếu bạn muốn một giải pháp tao nhã, nó sẽ là một chút công việc. Về mặt tươi sáng, một khi bạn đã thực hiện nó một lần, bạn có thể giữ nó trong thư viện mã của mình để sử dụng trong tương lai!


Tôi nghĩ rằng các mẫu trình chỉnh sửa / hiển thị tùy chỉnh và chất kết dính là giải pháp thanh lịch nhất, bởi vì nó sẽ "chỉ hoạt động" khi được triển khai. Không phát triển sẽ cần phải biết bất cứ điều gì đặc biệt để có được những ngày làm việc ngay chỉ cần sử dụng DisplayForEditorForvà nó sẽ làm việc mọi lúc. +1
Kevin Stricker

17
Điều này sẽ không hiển thị thời gian của máy chủ ứng dụng chứ không phải thời gian của trình duyệt?
Alex

0

Đây có lẽ là một búa tạ để bẻ khóa một đai ốc nhưng bạn có thể tiêm một lớp giữa các lớp UI và Business để chuyển đổi thời gian dữ liệu thành thời gian cục bộ trên các biểu đồ đối tượng được trả về và UTC trên các tham số thời gian đầu vào.

Tôi tưởng tượng điều này có thể đạt được bằng cách sử dụng PostSharp hoặc một số bộ điều khiển đảo ngược.

Cá nhân, tôi chỉ cần chuyển đổi rõ ràng dữ liệu của bạn trong UI ...

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.