Javascript将计划日期从本地时区发送到服务器时间 [英] Javascript Send Schedule Date From Local Timezone to Server Time

查看:53
本文介绍了Javascript将计划日期从本地时区发送到服务器时间的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在夏威夷.我想从Angular发送太平洋标准时间(PST)到C#Net Core API.它将保存在数据库中,并保存在太平洋标准时间.(我没有创建架构,只是注意).

I am in Hawaii. From Angular, I want to send Pacific Standard Time (PST) to C# Net Core API. It will save it in database and save in Pacific Standard Time. (I didn't create the architecture, just noting).

整个Angular应用程序的日期/时间都是参考PST编写的.

The whole Angular Application date/times are written in reference of PST.

示例目标是在太平洋标准时间下午4:30安排日期

Example goal is to Schedule Date at 4:30PM PST

我们今天学会了一个错误,如果我们发送日期"2021-03-17T16:30:00" ,我们的应用程序会创建 new Date("2021-03-17T16:30:00")在夏威夷时区中的解释有误.然后C#可能会做正确的事,并将任何时间都转换为太平洋当地时间(TimeZoneInfo.ConvertTime(dateTime,TimeZoneInfo.FindSystemTimeZoneById("America/Los_Angeles")).因此,我们错误地将其转换为7:下午30点.

We learned a bug today, if we send a date "2021-03-17T16:30:00" , our application creates new Date("2021-03-17T16:30:00") in Hawaii Timezone misinterprets. Then C# probably does the right thing, and converts any time to Pacific Local time (TimeZoneInfo.ConvertTime(dateTime, TimeZoneInfo.FindSystemTimeZoneById("America/Los_Angeles")). Thus we incorrectly convert to 7:30PM.

我们的API请求数据类型为日期.这个解决方案行得通吗?但是,我觉得最后4行不会解决夏令时的问题,否则会造成问题.

Our API Request Data type is in Date. Would this solution work? however, I feel last 4th line will not account for Daylight savings, or can create issue.

const inputDate = "2021-03-17T16:30:00";
const pstMoment = moment.tz(inputDate, 'America/Los_Angeles');
const clientTimeZoneName = Intl.DateTimeFormat().resolvedOptions().timeZone;
const clientMoment = pstMoment.clone().tz(clientTimeZoneName);
console.log(new Date(clientMoment.format())); // this will send to API

<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.1/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.33/moment-timezone-with-data-10-year-range.js"></script>

注意:代码解析不仅应在夏威夷使用,而且应在其他可能没有夏令时的全球性国家中使用.我们的计划日期选择器利用了字符串存储类型(inputDate).

Note: Code resolution should not only work in Hawaii, but other global countries which may Not have Daylight Savings Time. Our schedule datepicker utilizes a string storage type (inputDate).

Typescript类

export interface ScheduleDto { 
   scheduleDate?: Date;

scheduleDate: "2021-03-18T02:30:00.000Z"

C#类

public class ScheduleDto   
{
   public DateTime? ScheduleDate { get; set; }

....

return TimeZoneInfo.ConvertTime(ScheduleDate , TimeZoneInfo.FindSystemTimeZoneById("America/Los_Angeles"));

推荐答案

如果我理解正确,那么问题在于,您当前在客户端的方法只是创建一个 Date 对象,例如新日期("2021-03-17T16:30:00"),它将使用本地时区来确定您正在谈论的时间点.您希望始终将其解释为太平洋时间,但是由于DST,您不知道要使用哪个偏移量.

If I understand correctly, the problem is that your current approach on the client-side is just creating a Date object like new Date("2021-03-17T16:30:00"), which is going to use the local time zone to determine the point-in time you're talking about. You want it to always be interpreted as Pacific time, but you don't know which offset to use because of DST.

因此,问题的最终答案是-是的,您使用Moment-timezone编写的代码确实会应用正确的偏移量.但是,这有点冗长.实际上,您无需执行任何有关检测当前本地时区的操作.您可以改为使用以下方法构建 Date 对象:

So then, the ultimate answer to your question is - YES, the code you wrote using Moment-timezone, would indeed apply the correct offset. However, it's a bit verbose. You don't actually need to do anything with regard to detecting the current local time zone. You can instead just build the Date object with:

moment.tz('2021-03-17T16:30:00', 'America/Los_Angeles').toDate()

给出时刻的项目状态,最好使用Luxon(除非您已在项目中广泛使用Moment).在卢森堡,这将是:

Given Moment's project status, it would be preferred to use Luxon instead (unless you have already extensively used Moment in your project). In Luxon, that would be:

luxon.DateTime.fromISO('2021-03-17T16:30:00', {zone: 'America/Los_Angeles'}).toJSDate()

或者您可以使用 date-fns-tz .

重点是,由于要构造 Date 对象,因此始终会通过电线发送该对象的一些字符串表示形式.您似乎正在使用 .toISOString()序列化这些 Date 对象,这将发送等效于UTC的"2021-03-18T02:30:00.000Z"..最重要的是正确设置UTC时间点.

The point is, since you're constructing a Date object, you're always sending some string representation of it over the wire. You appear to be serializing those Date objects with .toISOString(), which will send the UTC equivalent "2021-03-18T02:30:00.000Z". Getting that UTC point in time correct is what matters most.

在您的.NET代码中,如果您将该值接收到 DateTime 对象中,则其 Kind 属性将设置为 Utc 因为字符串末尾是 Z . TimeZoneInfo.ConvertTime 将使用 Kind 属性确定转换的源时区,并且已将目标时区提供为太平洋时间.

In your .NET code, if you are receiving that value into a DateTime object, then its Kind property will be set to Utc because of the Z at the end of the string. TimeZoneInfo.ConvertTime will use the Kind property to determine the source time zone for the conversion, and you've supplied the destination time zone as Pacific time.

一种更简单的方法是在客户端代码中使用 Date 对象,而是通过网络发送预期的日期和时间,而没有偏移量"2021-03-17T16:30:00" .在您的.NET代码中, DateTime.Kind 将是 Unspecified .然后,您根本不会调用 TimeZoneInfo.ConvertTime ,因为您已经具有所需时区中的值.

A much simpler approach would be to not use a Date object in your client-side code, but rather you would send the intended date and time over the wire instead, without the offset "2021-03-17T16:30:00". In your .NET code, the DateTime.Kind would be Unspecified. Then you wouldn't call TimeZoneInfo.ConvertTime at all, because you already have the value in the desired time zone.

替代项:

对于TypeScript数据类型,您可以使用字符串.

For the TypeScript data type, You could use a string.

将来,当 Temporal 完成并完全集成到ECMAScript中时,您可以使用 PlainDateTime .

In the future, when Temporal is finished and fully integrated into ECMAScript, you could use a PlainDateTime.

这篇关于Javascript将计划日期从本地时区发送到服务器时间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆