this may be a stupid question, but I can't see which timezone the changeset was created in. Is all all the time converted to UTC?
Timestamps in OSM changesets are stored in UTC. This can be deduced from the suffix Z at the end of the timestamp.
From https://en.wikipedia.org/wiki/Coordinated_Universal_Time:
The time zone using UTC is sometimes denoted UTC±00:00 or by the
letter Z—a reference to the equivalent nautical time zone (GMT), which
has been denoted by a Z since about 1950. Time zones were identified
by successive letters of the alphabet and the Greenwich time zone was
marked by a Z as it was the point of origin. The letter also refers to
the "zone description" of zero hours, which has been used since 1920.
Since the NATO phonetic alphabet word for Z
is "Zulu", UTC is sometimes known as "Zulu time".
Related
I only want to get the current date object's timezone. The Date class in Swift does not have a way to do so. I have seen ways to convert from one timezone to another. But no way to do so extracting the timezone from a date object.
Why is that?
Is there a way to do so? Thoughts on how? Thanks
Dates don’t have time zones. They’re simply a point in time.
E.g., the moment in which Neil Armstrong stepped foot on the moon. You could describe that moment in UTC, or EST, or any other TZ (or even in other calendar systems), but they’re all referring to the same moment. That would be modelled by a singular date object.
By another analogy, an object has a width, but it doesn't know its unit. Its width can be measured in centimetres, inches, plank lengths or light years. These are all abstractions we put on top of the concept of distance, and they all describe the same thing.
Internally, they’re just a Double that counts the number of secs since the reference date. Clearly, there's no timezone there.
Any time zones you see relating to dates are just an interpretive layer on top of that (e.g. print will call .description, which will format it to your local tz for your convenience.).
I have a list of observations where each data point is a pair of a time expression (e.g. night, morning) and an hour in a 12-hr clock (i.e. 1, 2, ..., 12): Y = {<e_i, h_i>}_i={1,...,N}. I would like to estimate the distribution of hours in a 24-hr clock given a time expression (or equivalently, classify each data point to AM or PM).
I have a feeling EM would be useful here given the hidden AM/PM variable, but I'm struggling to define the parameters. In all other examples I've used EM for, something is assumed about the distribution that generated the observations (e.g. that it is a normal distribution, or document classification based on bag-of-words). But I'm not sure how to define it here.
I'd appreciate any help!
I ended up solving it as an ILP problem:
I defined a binary variable for each combination of 12 hr and time expression (true if it is PM, false if AM), and start time and end time variables for each expression. My constraints were the order of time expressions, e.g. morning ends before noon starts, etc. I maximized the number of observations that fit within the start and end time for each expression.
RFC 5545 and other standards like JSCalendar define a P1DT12H duration as one nominal day plus 12 exact hours. Normally this will be 36 real-world ("exact" or "accurate") hours, but:
If a Spring DST transition happens during the "one nominal day" part of that duration, then the accurate duration will be only 35 hours.
If a Fall DST transition happens during the "one nominal day" part, then the accurate duration will be 37 hours.
But what if the starting date/time is exactly one nominal day before a discontinuous period? For example, a P1DT12H duration added to 2020-03-07T02:30 in America/Los_Angeles where DST starts at 2020-03-08T02:00. In that case, what should be the calculated local time at the end of that duration?
Is it 2020-03-08T14:30? 2020-03-08T13:30? 2020-03-08T15:30? Something else? Also: why?
The problem is that the naive way of calculating the exact duration would be to add the date portion of the duration using nominal units, then convert that intermediate result to UTC and add the time portion of the duration using exact time. But that intermediate result is an invalid nominal time that's skipped, then the local time of that intermediate value is 2020-03-08T03:30 (3:30AM, not 2:30AM) because RFC 5545 says:
If the local time described does not occur (when changing from standard to daylight time), the DATE-TIME value is interpreted using the UTC offset before the gap in local times.
So using that interpretation of the spec, the final result after adding the 12-exact-hour time portion should be 2020-03-08T15:30 or 3:30PM.
Is this the "correct" answer according to RFC 5455? If not, what should be the answer and why?
Or is this an ambiguity in the standard and there's no objectively correct answer?
I was hoping someone else would answer. Here is my understanding:
Two concepts here:
Either one has the DTEND and is calculating the DURATION, which as you have established, will vary if there is daylight saving change during the event, OR
one has the duration and is calculating the DTEND. It is best to do that in UTC for safety sake.
RE your question:
But what if the starting date/time is exactly one nominal day before a discontinuous period? In that case, what should be the calculated local time at the end of that duration?
For calculating DTEND, nominal day at same time takes us to invalid time. If one uses UTC to calc that nominal day, one gets 3.30 am. The spec says:
In the case of discontinuities in the time scale, such as the change
from standard time to daylight time and back, the computation of the
exact duration requires the subtraction or addition of the change of
duration of the discontinuity.
I understand this to mean yes, when working out the CALCULATED duration (ie where you have DTSTART and DTEND) will vary depending in the events point in the calendar, as you have noted.
RE your question
But that intermediate result is an invalid nominal time that's skipped, then the local time of that intermediate value is 2020-03-08T03:30 (3:30AM, not 2:30AM...."
Yes, however in calculating further I think you went wrong adding the 12H to the local time. Spec says use the earlier UTC offset, which I take to mean use that to get UTC time, use UTC for the calcs, then convert back.
If the local time described does not occur (when changing from
standard to daylight time), the DATE-TIME value is interpreted using
the UTC offset before the gap in local times.
Note this is the UTC offset. So one nominal day takes us to 2.30am which does not 'exist' in LA on 8 March, so we use the UTC offset before the time gap. -8 hours which gives us UTC=10h30.
Plus 12H gives us UTC 22H30.
If we stay with the -8 offset for calculation purposes, we get local time 14:30.
*It is not 100% spelled out in the specification that this is it. More worked examples to confirm would be good.
Advice I have seen elsewhere is to store times in UTC time, do the calcs in UTC time, then for display, calculate local time.*
RE:
Is it 2020-03-08T14:30?
Is this the "correct" answer according to RFC 5455? If not, what should be the answer and why?
I understand it to be 14H30. I cross checked using PHP, with calcs in LosAngeles and in UTC time before DST & during DST, using both datetime->add https://www.php.net/manual/en/datetime.add.php and https://www.php.net/manual/en/datetime.modify.php and consistently got that answer.
I think correct is 2020-03-08T14:30 because if one uses the UTC offset as specified and calcs in UTC, that is what one gets.
PHP Workings
add a nominal day P01D
Before DST:
2020-03-06T02:30:00-08:00
2020-03-07T02:30:00-08:00 with modify
2020-03-07T02:30:00-08:00 add date interval
Over DST:
2020-03-07T02:30:00-08:00
2020-03-08T03:30:00-07:00 with modify
2020-03-08T03:30:00-07:00 add date interval
add a nominal day plus 12 H ie: P01DT12H
Before DST:
2020-03-06T02:30:00-08:00
2020-03-07T14:30:00-08:00 add date interval
Over DST:
2020-03-07T02:30:00-08:00
2020-03-08T14:30:00-07:00 with modify
2020-03-08T14:30:00-07:00 add date interval
For checking offset: https://www.timeanddate.com/worldclock/meetingtime.html?day=8&month=3&year=2020&p1=137&iv=0
For some duration-related calculations I need to convert values measured in "months" to other formats, such as years, days, or hours.
For example, what is the proper way to measure a month in terms of days? is it 30 days? or 30.4375 days? (365.25 / 12) and which format would be useful in which cases?
If you have any information on the casual/business use cases for such conversions it would be helpful too.
Unfortunately, there's really no single generally valid answer to your question.
If this is for business use, first check whether there are any existing relevant standards or business practices that define what a "month" means in your business context. If yes, you should follow that definition as closely as possible, however silly or awkward it may seem.
For casual use, the simplest solution is probably to pick any widely use date manipulation library and do whatever it does. The default behavior may not be perfect, but it's probably at least close to a fairly sensible compromise of the many contradictory expectations that users of such a library may have.
OK, but what if you insist on rolling your own solution? In that case, the first choice you should make is how you want to represent date / time values. There are at least two common choices:
The first option is to store dates / times using a simple linear count of fixed time units from a given epoch, such as Julian days or Unix timestamps. This provides a simple and compact date/time representation, makes comparing timestamps and simple date/time arithmetic (like adding n seconds to a time value) easy, and ensures that any time value corresponds to a (more or less) unique and well defined point in time.
The downside, as you've noticed, is that arithmetic using "fuzzy" time units like months or years gets difficult: you can define a year as 365.25 days (or as 365.2425 days, to take into account that only 97 out of every 400 years are leap years in the Gregorian calendar) and a month as 1/12 years, but this will cause adding a year to a date-time value to also shift the time of day by (about) 6 hours, which may be unexpected.
This approach also doesn't let you easily represent "floating" time value, like times of day without a specified date and time zone. (You can sort of deal with floating time zones by doing your time math in UTC and just pretending that it's in your local time zone, but this can cause weird stuff to happen around DST changeovers.) Conversely, it can also cause difficulties if you need to represent imprecise date/time values, such as dates without a time component.
In particular, if you choose the "natural" representation, where imprecise datetimes are represented by their starting point, so that e.g. an unspecified time of day defaults to 00:00:00.0, then anything that causes the time part to be reduced by even a fraction of a second — like, say, shifting to a later time zone, or subtracting a fuzzy time unit that is not an integral number of days — will flip the date part to the previous day. For example, with this representation, subtracting one year (= 265.2425 days) from January 1, 2014 will yield a date in 2012 (specifically, December 31, 2012, 17:56:32)!
You can avoid some of these issues by representing imprecise date/time values by their midpoints instead, so that e.g. the date 2014 is treated as shorthand for June 2, 2014, 12:00:00. What you lose, with this representation, is the ability to build datetimes just by adding up components: with this representation, 2014 + 5 months + 3 days isn't anywhere near May 3, 2014.
Also, just when you think you've at least got simple non-fuzzy time arithmetic unambiguously sorted out, someone's going to tell you about leap seconds...
The alternative approach is to store datetime values in decomposed year / month / day / hour / minute / second / etc. format. With this presentation, time intervals are also naturally stored in a decomposed format: "one month + 17 days" is, in itself, a valid time interval in such a representation, and need not (and should not) be simplified further.
This has a few obvious advantages:
Fuzzy unit arithmetic is (conceptually) simple: to add one year to a date, just increment the year component by one.
Imprecise date/time values can be naturally represented: for a pure date value, the time-of-day components can simply be left undefined (= e.g. represented by negative values for the undefined components, or simply by having each datetime value store its precision).
You have precise control over when and if rollover occurs: adding a year to a date in 2014 will always yield a date in 2015.
You can also support floating time values, such as times of day without a specified date, or dates of year without a specified year. Floating time zones also become supportable.
That said, there are some disadvantages, too:
Implementing date arithmetic gets more complex, since you have to deal with non-trivial carry/borrow rules. (Quick! What's the date 10,000,000 seconds after May 3, 2014?)
You'll still have ambiguities with month arithmetic: what's the date one month after January 31? And does it depend on whether it's a leap year or not?
You can allow such a format to store "impossible" dates like "February 31", with an optional method to normalize them to, say, February 28 (or 29, for a leap year) later. This has the advantage of preserving (some) arithmetic consistency: it allows (January 31 + 1 month) + 1 month to equal March 31 as expected.
In some ways, though this merely postpones the problem: presumably, January 31 + 24 hours should fall on February 1, but what day and month should January 31 + 1 month + 24 hours fall on? The "obvious" choice would be March 1, but whatever you choose, there will be some sequence of arithmetic operations that will yield inconsistent results.
Here's the deal. I have a latitude/longitude set of a location. I need to figure out what the current time is in that location. Here's how I was getting it before:
NSDateFormatter *theFormatter = [[NSDateFormatter alloc] init];
[theFormatter setDateFormat:#"h:mm a"];
NSDate *todaysdate = [NSDate date];
NSString *todaysDate = [theFormatter stringFromDate:todaysdate];
[theFormatter release];
However, I realized that this will give the time for the user's current location. Is there an API somewhere that gives me the time based off of a lat/lon pair?
Thanks in advance.
Unfortunately timezones (and time in general) is never as simple as you would like.
For a simple approximation you can follow jer's suggestion. Longitude ranges from -180 to 180 degrees, there are 24 hours in a day, so you get 15 degrees of longitude per time zone. Center those time zones on 0 degrees longitude so UTC extends from -7.5 to 7.5, UTC+1 is from 7.5 to 22.5, UTC-1 is from -7.5 to -22.5, and so on. You would then have a very simplistic, and wrong, model of how we use time zones.
Take a look at this map of time zones.
Time zones are not well ordered; regions in UTC-1 are adjacent to regions in UTC-3.
UTC-9.5, UTC-4.5, UTC+3.5, UTC+5.75, and UTC+13 are all valid time zones and actively in use.
Once you get that sorted out then you can start to consider daylight savings time.
No, you will have to write one. Since the latitude and longitude points are well known, and timezones are also well known (though change periodically), all you have to do is map where the lat/long boxes are in given timezones, and calculate if your current position is in which one of those boxes. Once you know which box you're in, you'll have enough info to figure out what your time is.
This is not a trivial problem -- but it's not one without a solution. Services like Geonames and WeatherBug are very restrictive and/or costly so don't start developing something before you thoroughly understand their terms of service.
Here are the steps that I followed for my Appcelerator-based iPhone app:
Locate a list of coordinates that describe all timezones as polygons and read them into a SQLite table.
Make a best guess of which timezone the user is in (or is seeking), based on the longitude. This will be several zones.
Pull the polygons of each of the best-guess timezones from the database and run each one through a find-point-in-polygon algorithm. The one that returns true is the correct timezone.
If you a not concerned about Daylight Saving Time, you're done, otherwise, you have a mess to deal with. The landscape of DST is completely illogical and changes frequently. The best I could do was to Google "Daylight saving time rules" (start looking here: Sources for Time Zone and Daylight Saving Time Data) and be prepared to do a lot of work setting up list that you can use for the calculation. Mine still does not work perfectly after a lot of tweaking.
Use this data dump and import it into your program. Then locate the country in which your lat/long exists and it's time zone. You can then calculate what time it is at a specific lat/lon.
Geonames
I've written a small Java class to do this, with the data embedded in the code. It could be easily translated to ObjectiveC. The database is embedded in the code itself. It's accurate to 22km.
https://sites.google.com/a/edval.biz/www/mapping-lat-lng-s-to-timezones