What would you recommend to store dates using Firebase between a datetime and a timestamp, and why?
Use a timestamp as this is locale-agnostic and does not require formatting and parsing agreements between clients. It's also a bit shorter.
Furthermore, utilize Firebase.ServerValue.TIMESTAMP, rather than trusting the clients to have their clocks set correctly. If, for example, a client's clock is off by 5 minutes and you utilize the client timestamps in a chat conversation, then rendering back the messages, the time shown would appear to be 5 minutes in the future for other users.
Related
I have a .NET web site that captures a C# DateTime value and stores it in database with UTC value. Upon showing that datetime value on web page, what I want is that date time UTC value to be converted to web user's local time zone properly. So web users in different time zones will see the displayed date time value with different date time results.
I have 2 following approaches. I do not know which is the best and correct one.
Approach 1: Let C# server side codes to convert the UTC DateTime value to local date time using .NET library method DateTime.ToLocalTime() and pass that converted value to client side to display without any further client side codes.
Approach 2: I do not do any time conversion using C# server side codes. Instead, I simply pass the UTC datetime value to client side and I will use some client side (javaScript or some JS library) codes to do the conversion before displaying it to web user.
Question 1: Approach 1 or Approach 2 is the best and correct one?
Question 2: The .NET library DateTime.ToLocalTime() method will convert a datetime value to local time of web user; web server's local time; OR web user's computer OS time?
Question 3: How can I test my web page with different time zones to see the best/correct approach working?
Thank you for your help.
I suggest that all date/times be stored in UTC on the server and that, in your case, you do the web client timezone conversion on the client side. I suggest the Moment library for client-side operations. If you use Moment, look at the guess() method for determining the client's current timezone.
By the way, you might want to determine the client's current timezone periodically in case 1) the user in on a mobile device and physically moves to another timezone or, 2) the user's session lasts long enough to transition from Daylight Savings Time (DST) to Standard Time (STD) or vice versa.
Now, I said "in you case" because, based on your question you don't seem to need to worry about calculating time intervals between 2 date/times. If you need to do that you also have to consider the complication of changes in a timezone from 3 sources:
Changing from STD to DST (and vice versa) that occurs twice a year in many timezones.
Changes to the UTC offset of a timezone that sometimes happens when a government implements a change.
Changes to the date/time when a location converts from STD to DST or vice versa.
Also, you might need to consider the complication of dealing with the potential for a local time corresponding to two UTC times! This can happen when a local time for a location falls within the 1 hour preceeding the date/time when that location converts from DST to STD. That 1 hour period is repeated when a 'fallback' from DST to STD time occurs and so you need to resolve which of 2 possible UTC times you want to store in your database.
If any of the above timezone complications might exist for you, consider storing a location along with the date/time since this context is required for timezone calculations. The location can be lat/lon which you would need to map to a timezone or you could keep it simple and store just the timezone. Lat/lon is sometimes more desirable since sometimes governments decide to move a location into a new timezone (but this is pretty rare).
I create project with php Laravel framework and VueJS and I want to get the difference between server time and client time to process some data time out by Javascript in the client browser.
How can i do that?
I need to change the format of one of the dates to be available to manage by other language functions and property.
how to sub (minus) Carbon::now() got from php api Date.Now() in JS.
I do that to get the difference between client clock and the server.
In order to "speak" in dates, the best practice is to work with timestamps.
The server can have its own timezone offset which is why it is best that it will expose any managed dates in UTC.
The client, on the other hand, will need to convert the UTC timestamp to its locale date, which can be done by adding its timezone offset.
Having said that - you will probably want to calculate the data timeout on the server, since the client can be bypassed, thus exposing a timed-out data to potential hackers.
Hope this helps :)
Is it a good practice to compare the date and time using the epoch(UTC) time?
I checked it on internet, but did not got example of this. Does this approach has any negative?
if(date_utc1>dateutc2){
//do something
}
Here date_utc1 and date_utc2 are time in epoch
I gathered from the comments that one of the dates is a server-side generated date, but the other is a client-side generated date. Without fully understanding the logic involved here, I´d just like make a short note (sorry don´t have reps for comments) that these two clocks may not fully agree on time (represented in epoch or not).
If possible, a better solution is to only rely on one (the server´s) clock. When the client initially receives data from server, the client persist the server-side timestamp (needs to be part of the response). Down the line, if the client wants to check if the server has more data, the persisted value should be sent back. This way we are sure that the server only returns stuff that has been changed since the last fetch.
You can use Date.now() to get the current time in all recent browsers. You could also use +new Date() to obtain the same number in older browsers if you need to.
Since the data returned from the server is already a number in this milliseconds-since-epoch format, it makes sense to use this information for comparisons, since there is no other calculations or parsing of the data coming from the server that must be done.
I don't believe there are any negatives here.
I am trying to create a scheduling application. The front end\UI is developed using JavaScript. The back end is a ASP.NET Web Api application which uses MSSQL server as the database. From the UI, user will schedule a job which can run daily/weekly/monthly. Each job can run for maximum of 3 months. The job will run on the server side at the specified time.
Assume user come and selects a job which will run for a week (From 23-Nov to 29-Nov) at 10 AM local time. In this case, I will make seven entries in the database starting from 23 nov (One for each day). Each row will have Start time, Start Date and some status related columns.
I have following querstions:
How do I store time information (10 AM in this case)on SQL server?
Should I get the time using JavaScript on client machine and then convert the same to UTC?
Should I get the time using JavaScript and also save the user time zone information?
What happens when DST related changes take effect?
Will library like momemnt.js will help in this scenario?
I am thinking of saving user timezone information and the saving his local time on the server.
Warning - Scheduling properly is hard. There's a lot more to consider. Please read this and this. Most of your questions are addressed there (though from the perspective of other languages, the challenges are the same).
You might also take a look at Quartz.net, which is sufficient for many scenarios.
To answer your specific questions:
How do I store time information (10 AM in this case) on SQL server?
For the recurrence rule, store the local time of the event. SQL Server has a time type, which works well for storing the time of day. You will need other fields for tracking the time zone, the start date, days of the week, and other pattern information.
For the specific instance that is scheduled to run, you calculate the UTC datetime based on all the information in the recurrence rule. At minimum, you schedule the next occurrence, and recalculate after each run. In some cases, you may decide to project the next N occurrences, depending on what you need to show to the users. (You could also use a datetimeoffset for this purpose. See datetime vs datetimeoffset.)
Should I get the time using JavaScript on client machine and then convert the same to UTC?
Should I get the time using JavaScript and also save the user time zone information?
To answer both questions: For scheduling, you should not discard the original input, which will be in the local time zone of the event being scheduled. That may or may not match the time zone of the user. You will need to ask the user to select the time zone of the event.
What happens when DST related changes take effect?
That's up to you. You will need to test this thoroughly. In general, there is a period of local time that is skipped, and a period of local time that is repeated.
When it is skipped, you have to decide when to run the event. Options include: 1) before the skipped time, 2) after the skipped time, and 3) not at all. In most cases, the preferred option is to run after the skipped time, by advancing the local time by the DST bias (usually 1 hour). For example, a daily event scheduled to run at 2:30 every day in Pacific time would run at 3:30 on the day of the spring-forward transition.
When it is repeated, you have to decide when to run the event. Options include: 1) at the first occurrence, 2) at the second occurrence, and 3) at both occurrences. In most cases, the preferred option is to run at the first occurrence only. For example, a daily event scheduled to run at 1:30 every day in Pacific time would run at 1:30 PDT, and not at 1:30 PST.
Exceptions to this include dealing with businesses that are open late into the evening and choose to stay open for the repeated hour. For example, a bar, restaurant, or movie theater. It is highly dependent on the specific use case and the choices made by the specific business.
Will library like moment.js will help in this scenario?
Not from a scheduling perspective, no. It can help with parsing, formatting, and validating input though. You might also use moment-timezone to help with selecting the event's time zone. If you were running this with node.js on the back end, then perhaps there would be more benefit.
The biggest challenge is actually one you have not talked about, which is maintaining the time zone data on your server. In your C# code, I recommend using Noda Time for this, instead of TimeZoneInfo. You can then update the tzdb data yourself as needed. You also need to think about the workflow of rescheduling the UTC instants of each occurrence, in the case that a time zone has changed its offset or daylight saving time dates.
I searched this on goolge and stackoverflow but couldn't find any satisfying answers.
I had some troubles with datetimes and timezones and i was wondering what the best way would be to transfer datetimes back and forth between server (c#) and client (javascript) ignoring the timezone.
I use JavaScriptSerializer on server and JSON.stringify on client.
Currently i convert the dates into ticks.
Any advice appreciated.
Actually time SHOULD be different because of timezone. Hours (and sometimes minutes if zone definition includes minutes) are changed as well as zone, when client deserializes datetime in a different timezone. If you want client to get same hours and minutes clear zone info before serialization.
DateTime.SpecifyKind(date, DateTimeKind.Unspecified);