I need to parse strings with time like '09:21:15 EST' (where EST is US Eastern timezone), so that the information about summer / winter time (daylight saving time) is correct, so that UTC−05:00 is used for winter dates, and UTC−04:00 for summer dates.
It is also necessary to support the direct setting of the UTC offset - '09:21:15 UTC−04:00', in which case daylight saving time should not be taken.
I Didn't find anything intelligible and sensible in Qt documentation for QDateTime, QDate, QTime, QTimeZone etc.
Is there an easy way to solve this problem?
In general, in any language, what you ask cannot be done reliably.
EST is not a time zone. It's an English abbreviation for an aspect of a time zone.
There are places that use EST without EDT, such as Jamaica for example. See more here.
There are non-English abbreviations to consider, such as HNE that's used in places in French-speaking Canada such as Montréal.
Many abbreviations are ambiguous. For example CST could be Central Standard Time, Cuba Standard Time, or China Standard Time.
Many time zones don't have any abbreviation - even in English. They are sometimes given invented (made up, artificial) abbreviations that aren't legal or in common usage, but in reality they are referred to by their country name or only by their UTC offset (for a given timestamp).
In order to convert between time zones reliably for multiple timestamps, you need an IANA time zone identifier, such as "America/New_York". QTimeZone can work with these.
On any given timestamp you can have an offset from UTC, such as -05:00. You can set an offset when using QDateTime.
If you are absolutely sure you are only working with timestamps from North America containing common English abbreviations, you could build and use an opinionated mapping between string and offset, such as "EST" == -5, "EDT" == -4, "CST" == -6, "CDT" == -5, etc. But it can only map abbreviation to offset, not to a time zone. (See also "Time Zone != Offset" in the timezone tag wiki.)
Qt likely has the features you need already implemented.
With QDateTime::fromString you can use t in the format string to mark timezone characters.
Have a look into this question as well: Qt QDateTime from string with timezone and daylight saving
There you can get an example, which shows that you need the QDateTime in the LocalTime specification to be able to deal with daylight saving times.
However, QDateTime::offsetFromUtc is dependent from the QDateTime's current specification...
I guess, you would need to always convert the QDateTime object to the same TimeSpec before comparing offsetFromUtc
Related
Kusto provides functions to get the start- and end-day of the week. These are invoked through startofweek() and endofweek(). startofweek() returns Sunday, and endofweek() returns Saturday.
In some countries, weeks are from Monday to Sunday, which I have been unable to locate how to change.
Is it possible to set the culture in kusto, such that startofweek() and endofweek() would return Monday and Sunday respectively?
No, I have not seen a setting where culture can be set in Kusto. Where operating systems and applications which make it possible to set such configurations, I see Kusto being being fairly basic and similar to .NET libraries where the DayOfWeek enum begins with Sunday at index 0 and there is no way to change that foundation.
The documentation indicates that "Start of the week is considered to be a Sunday." so I believe that is that. It is up to us users to adapt from there. (https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/startofweekfunction)
I'm sure you have done this yourself already, but here has been my approach.
startofweek(now()) + 1d
endofweek(now()) + 1d
I need to replicate this date command output configuration in my server to replicate a troubleshoot.
I have found this command to change the timezone but I can't find how to change it to a "none" timezone.
# mv /etc/localtime /etc/localtime.backup
# ln -s /usr/share/zoneinfo/Europe/Brussels /etc/localtime
First, this question is slightly off-topic for StackOverflow. I'll go ahead and answer, but next time consider non-programming questions like this should be on a different site in the Stack Exchange network, such as Unix & Linux or ServerFault.
The man page for date shows %Z displays a time zone abbreviation - which is not the same thing as a time zone name or identifier. It shows only that you have a time zone set on that computer where the abbreviation is numeric.
Numeric time zone abbreviations occur in the tzdb where there is no official or defacto English time zone abbreviation. For example, while in the USA we would use PST to abbreviate Pacific Standard Time, many time zones do not have such a concept. In the past, certain time zone abbreviations were invented (made up, really) to fill this gap, but these have been systematically removed from the tz data in the last few years. Thus, if a time zone doesn't have a local English abbreviation, then you will see a numeric offset in the "abbreviation" returned by %Z instead.
From your StackOverflow user profile, I see you are in Chile. I will guess then that your time zone is set to America/Santiago. The "abbreviation" -03 is currently returned by that zone during daylight saving time (also known as summer time), and will return to -04 during standard time. The tzdb used to have the invented abbreviations "CLT" and "CLST" for this time zone, but these were replaced with the numeric abbreviations in release 2017a.
Thus, the time zone you should be setting is America/Santiago.
ln -s /usr/share/zoneinfo/America/Santiago /etc/localtime
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)
yes this is an iOS programming question.
I need to calculate the exact time the RMS Titanic sank for its 100 yr anniversary.
It sunk at 15th April 1912 2:20 a.m.
Stupid Question you say. 100th year anniversary is
15th April 1912 2:20 a.m.
+100 years
15th April 2012 2:20 a.m.
But I want an alarm to go off in any timezone in the world exactly and need to handle timezones, and things like British Summer Time being one hour ahead yet it didnt come into effect till 1918.... but as of today 25 mar 2012 London IS in BST so one hour ahead.
Im confused on timezones. We have GMT and UTC. The ships sank at 49° 56' 49" W, 41° 43' 32" N so few hours ahead of London.
-49.94822196927015
41.72713826043066
Whats the correct way to enter a historic date into NSCalendar
and to add 100 years to it exactly and get back the right time
in the users current timezone?
I notice theres Japanese and Islamic calender formats in NSCalendar options. Can iOS device change their dates to these calendars?
And if this was the case. how would I convert from Gregorian to say Islamic?
nice brain puzzler to start your week :)
(There's no code here, as I've never used the iOS API. However, I have some experience of date/time APIs and the oddities they throw up, so I hope you find this answer useful anyway.)
What's the correct way to enter a historic date into NSCalendar
and to add 100 years to it exactly and get back the right time
in the users current timezone?
It really depends on what you mean by "100 years" - it's not like that's a fixed amount of time really.
I would take the UTC instant at which it sank, apply the user's local time zone, and then add a hundred years to that. However, you then need to consider that the result may not actually be a valid local time in that time zone.
For example, suppose you're in a time zone where at the instant of the sinking, it was 1:20am... but in that time zone, 15th April 2012 is when the clocks change - and they skip from 1am to 2am. In that case, 1:20am never occurs... so you could potentially pick 12:20am, the instant before the DST transition, the instant of the DST transition, or 2:20am, depending on what you think is appropriate.
Another possibility to consider is the opposite - suppose it's a DST transition which goes from 2am to 1am... so 1:20am actually occurs twice. What would you want to do in that case? You probably shouldn't make your app celebrate the anniversary twice!
Another option which removes this possibility of ambiguity and discrepancy is to work out what the offset from UTC in the user's time zone was at the exact time of the sinking, then add 100 years to the UTC value (which will never have any DST transitions) and apply the same offset again.
I notice theres Japanese and Islamic calender formats in NSCalendar options. Can iOS device change their dates to these calendars? And if this was the case. how would I convert from Gregorian to say Islamic?
I don't know on that front, I'm afraid.