What is the best way to know what UTC timezone has, let's say, 7:00 AM right now. Or find the one that is closest.
One way would be to have an array of all the timezones (there are only 39, not a big number), loop through them, find the one with least difference.
But, I'm looking for a better solution. Is there?
Related
I have an application that uses subscriptions for each member that joins. I'm having some issues with dates and calculations related with it. For example, let say a member joins on 2/10/2020 at 10:00. When the user submit the request to the server to process the subscription (the server is using UTC) the date that is being calculate is 2/10/2020 16:00 (because I'm -6:00 hours from UTC). This scenario is OK at this point, because the date is still the same (no matter the time). But, if we replicate this scenario when the user joins for example 2/10/2020 at 19:00, when the request is received and calculate the date, the result is 2/11/2020 01:00, and that produces an error in the invoice because the billing date of the invoice is wrong (one day after). What is the best way to implement this? I have read a lot of this topic, but most of the pages and questions are related in the other way, server to client, to parse of format dates to display to the user.
I have several questions related with this process.
Should I sent the date for the UI to the API? Or the timezone and
based on that, calculate the date in the API? (since the server have
UTC)
Moment.js library have a way to solve this or should be better with vanilla Javascript using Date?
Is there any HTTP header for the request to handle the time or date?
This really depends on what behavior you want to have. Before you try to fix anything, think through and decide on the exact requirements for what the billing date should be based on.
Is the user's time zone relevant? If so, you'll likely need to know what the user's time zone is. You'll be potentially assigning different dates to different invoices even if they're using the same UTC point in time. Your business might get confused on why some customers have invoice dates before or after the business day.
Or maybe the time zone of your company is more relevant? Many business work that way. All of your invoices will be aligned, but some customers might get confused on why their invoice date is before or after their current date.
Or maybe some customers snap to time zones of nearby offices, in the case of businesses with offices around the world.
Only you and your company can decide this. There are probably other options I'm not thinking through here. It's a business decision, not a technical one.
On your three questions:
That depends on what you decide above.
Libraries are a good idea for simplifying your code, but they're not a hard requirement. You can use the Date API, if you know what you're doing, but you may find libraries easier to work with. Also, Moment is in maintainance mode. For new development, the Moment team recommends you use Luxon instead of Moment. There are other popular modern libraries also, including date-fns and js-Joda.
There's the date header, but that's not going to help you with this.
I am updating an application to use NodaTime to fix many existing time issues with our data and processes.
I will need to resolve timezones from a mobile app that sends IANA timezone names. I will need to support conversions to UTC using custom offsets (i.e. hard coded -04:00). I may or may not need to support Windows timezone names as well.
For all of this, I am wondering if I need additional packages. How do TimeZoneConverter and TimeZoneNames work alongside NodaTime? Are there any other additional packages I should use alongside NodaTime?
Our ultimate goal is to get all data persisted as Utc and convert to/from user time only for display or accepting user input.
You don't need any extra packages for that scenario, as far as I can see.
For IANA IDs, just use DateTimeZoneProviders.Tzdb
For "raw offset" IDs, you can use any time zone provider, asking for an ID of the form "UTC+01:00" etc. (So you'd need to add the "UTC" prefix.)
For Windows zone mapping, you can use TzdbDateTimeZoneSource.Default to get the default TZDB information, then use the WindowsMapping property to get a WindowsZones object you can use for mapping.
TimeZoneConverter may well be simpler to use for the last bullet point, but it's not required. The IANA IDs it provides should work fine with Noda Time.
TimeZoneNames is more about displaying time zone names to users. If you don't need to do that, you probably don't need the package.
Note that persisting all data as UTC may be a really bad idea - it's hard to tell without knowing more about your application. If you only deal with values in the past, or if they're fixed instants in time, that's fine. But if you're allowing users to schedule future events, I'd store the values that the user gave you. Here's an example of why...
Suppose the user says they want to schedule an event for Europe/Paris at 9am on December 1st 2021. If you convert that to UTC now, you'll end up with 2021-12-01T08:00Z, because the current time zone rules say that Paris will be at UTC+1 in December 2021.
However, it's entirely possible that between now and 2021, France will have changed its time zone rules to be on "permanent daylight time", i.e. UTC+2 all year round. At that point, your UTC value of 2021-12-01T08:00Z would correspond to 10am in Paris on the given date - contrary to what the user specified.
It's fine to convert to UTC as well so that you can create a totally ordered view of the data, so long as you retain enough information to perform that conversion again every time there's new time zone data.
As I say, that may not be an issue for you, but it's worth knowing that the "received wisdom" of "Always store everything in UTC" is really not good advice for all scenarios.
I am playing around with NodeMCU on an ESP8266. I have a Date String and a Time String from a Web Request like this:
15.07.16 (German format DD.MM.YY)
19:50 (24 hours format)
These DateTimes lay usually a little bit in the future. I want to get the number of minutes from the current time to the time from my strings above.
I guess I have to create a time object from the strings and then compare it to the current time. But how can I do that with Lua?
Unfortunately there is no os Library on NodeMCU (or I might have missed how to enable it).
Calculating the difference manually would be a huge pain which I would like to avoid. Does anyone know a way to compute that with available or external libraries?
Thanks for any support!
There's a pending PR for rtctime that does the exact opposite, Unix epoch to UTC calendar.
If you convert your strings to a Unix epoch X you could do
-- delta in minutes
local delta = (X - rtctime.get()) / 60
You can either calculate X yourself, which is far from trivial due to leap years & seconds and other date/time oddities, or your can send a request to http://www.convert-unix-time.com/api?date=15.07.2016%2019:50&timezone=Vienna&format=german and extract the timestamp from it.
First you get the numbers from the strings using Lua's string library:
https://www.lua.org/pil/20.html
https://www.lua.org/manual/5.3/manual.html#6.4
Then you do the time calculations using Lua's os library:
https://www.lua.org/pil/22.1.html
https://www.lua.org/manual/5.3/manual.html#6.9
I won't give you more information as you did not show any own effort to solve the problem.
Addon:
As you don't have the os library (didn't know that) you can simply calculate that stuff yourself.
Get the month, year hour and minute number from the strings using string.sub or string patterns.
Then simply calculate the time difference. You know how many days each month has. You know how many minutes per hour and how many hours per day.
Determine if the year is a leap year (if you don't know how: https://support.microsoft.com/en-us/kb/214019)
How can I get the highest high for a specific time span, e.g. from 08:00 - 10:00 am using a pyalogtrade or ta-lib indicator.
Of course I could write two if statements to check the time on the current bar, but I thought there must be a more elegant way to do it.
You could use technical.highlow.High: http://gbeced.github.io/pyalgotrade/docs/v0.17/html/technical.html#pyalgotrade.technical.highlow.High
I thought of Integer 16, because it's easy to calculate years, depending from it.
String is good for searching, for ex. it's easy to find year 78 as substring from 1978.
And it's also possible to keep year as Date.
What's the best practice?
I would think that storing something that involves a date of some kind would be best stored as an NSDate simply because it's pretty likely that when you pull that value back out, it will be for displaying some kind of date. I can't imagine that XCode would go out of the way to make NSDate so accessible in Core Data unless they had a good reason.
It could also be optimization...
Lastly, it's all about the circumstance. Like you had stated: yes, sometimes saving an object as a string is wise for various reasons including searching. But to answer your question directly, I would go with NSDate predominantly.
I'll stay with Integer 16, because it's the way how it's done in the book "CoreData for iOS".