OK here is a hardcore question that me and my friend are debating the proper programming solution for.
Let's say I'm running a business in New York at time UTC-4.
My sales rep based in San Francisco, whose time is 11:00 PM on December 31st, 2013 (which is 1:00 AM, January 1st, 2014 in my time) makes a sale that nets the company $1,000,000 USD. He enters the sale in the system as happening on December 31st, 2013, but really, in my time, it happens on January 1st, 2014.
For my 2013 report, do I include the $1,000,000 USD as profit, or does that go in my 2014 report?
A related question to hone in on the problem... how do most companies calculate daily sales for December 31st? Is it the last 24 hours from midnight in the company's HQ timezone, or is it for December 31st from each of it's market's time zones aggregated?
Further, if you only have the date (YYYY-MM-DD) entered for a sale, how should that be converted stored in UTC, being that a UTC day spreads over two unique dates?
Here's a helpful tool I've used to analyze this question:
http://everytimezone.com/#2013-8-27,-420,6bj
From a practical perspective:
It probably wouldn't matter which business day you recorded the sale. Many business end their days early, not necessarily at the stroke of midnight.
Some businesses might use the time zone of their headquarters, and some might use the time of the location where the sale was made. Either approach might be valid.
Of course, if this is an actual concern then you should ask an accountant or tax attorney. The answer may be different depending on your industry, state, or country.
As far as the technical parts to your question:
A date without a time or time zone is just a date. Think of it as a logical position on a calendar - not as a unique moment of instantaneous time.
Without additional context, you can't convert it to UTC. Or any other time zone for that matter.
Since UTC is a timekeeping system and not a time zone, then technically there is no such thing as a UTC day, but that is just semantics. Still, the idea of a "UTC day" would still only cover one calendar "date" - since that is part of the definition of what a "date" is.
It's just that the "UTC day" doesn't align with a "New York day". Just like a "New York day" doesn't align perfectly with a "Los Angeles day".
To blow your mind even more, consider that not every local day is 24 hours. Due to daylight saving time transitions, a "day" might by 23, 23.5, 24 24.5, or 25 hours long. Of course most are "standard days" - which are exactly 24 hours.
If you can keep separate that local time is a position on a calendar, while instantaneous time is universal, then you will find that it all makes sense.
That site you referenced has a nice visualization, and I reference it a lot. But IMHO it should have a different name because it doesn't cover every time zone. Use it carefully. See the IANA database discussed the timezone tag wiki, which has over 500 zones.
I don't know what language or database you are using, but you may find the concepts I described recently in this post on working with Date and Time in RavenDB useful. Specifically, read the section titled "Time Zone Conversions". Even if you use some other technology, the same concepts will apply.
Related
When I look at the data in Audience Overview and select one of the country segments I’ve set up, for certain time periods I get completely different numbers than those when I’m looking at the segment “All Users” in Geo/Locations.
In below image, "users" from United Stats are reported as 1,773 for period of 2nd May, 2018 to 30th Apr, 2019 (previous period comparison).
But if run country specific report for 2nd May, 2018 to 30th Apr, 2019 - count of users from United Stats are 6,331.
It would be great if you can give any insight into why GA providing diffrence counts.
Thanks,
Chintak.
If a segment contains visitor data, date range is automatically limited to 93 days from your start date. However, your time interval is much higher so the problem I would say is in the configuration of your segment.
See the screenshot below:
I always had conceptual troubles with date values being represented as objects without time (SQL for instance has the type DATE beside DATETIME). The same thinking often creates issues in languages that always store dates along with a time (e.g. C#'s DateTime). Suddenly timezone bugs pop up and the developers insist that all that timezone hullabaloo can be ignored, because their DateTime is actually "just a date". But what does that even mean?
The way I see it, such a "plain date" can be interpreted in only two ways:
From the perspective of points in time (i.e. "instants") one might infer that "2019-09-17" means the start (end) of the day, which is "2019-09-17 00:00:00" ("2019-09-17 23:59:59"). Hence timezone information is relevant and we are not talking about "just a date".
The other option is that the date is supposed to mean the whole day, so we are actually talking about a timespan from "2019-09-17 00:00:00" to "2019-09-17 23:59:59" and timezone information cannot be ignored either.
I argue that all use cases for "plain dates" fall in either of the two categories and that time/timezone can only be ignored if the software will only run on and communicate with systems configured with the exact same timezone.
Can someone provide a counter example or a third interpretation?
The "holiday" is an example of a date without a time, and even without a time zone.
Most holidays are religious in nature, and I don't want to start a religious war, or get sidetracked by minutiae. So as an example holiday, I'm going to pick Earth Day: April 22 of each year in the civil calendar.
If you write software that deals with holidays, said software isn't necessarily dealing with an instant in time across the entire planet (though it could do that in addition to tracking holidays). Instead it carries the concept that maps April 22 of each year to Earth Day. And it is irrelevant that some people will celebrate Earth Day hours before or after other people.
If a client wants to know exactly when Earth Day starts/ends for him, then he can translate "the date" into specific instants of time using his particular time zone. The need for that translation does not diminish the value of the date (say 2020-04-22).
C++20 will have several types to represent a "timezone-less date" such as 2020-04-22 using different data structures:
local_days // day 18374 == April/22/2020
year_month_day // year 2020, month 4, day 22 == April/22/2020
year_month_weekday // year 2020, month 4, 4th Wed == April/22/2020
I have a Redshift data table where all time values are stored in CST and I convert the time values to the respective timezone based on the zip code (location).
While I do that, I understand that all time values are in Standard time and hence my function usage is
CASE WHEN **** convert_timezone('CST', 'EST', time_column)
WHEN **** convert_timezone('CST', 'MST', time_column)
....
END
This may not be applicable once we enter into Daylight Savings time. How can I take care of this such that I do not modify the SQL query again in 2018 March and in future?
Don't use time zone abbreviations. The are somewhat ambiguous, and can only refer to one aspect of the time zone. Instead, use a full IANA time zone identifier, such as America/Chicago for US Central time.
This is explained well in the Redshift docs:
Using a Time Zone Name
If you specify a time zone using a time zone name, CONVERT_TIMEZONE automatically adjusts for Daylight Saving Time (DST), or any other local seasonal protocol, such as Summer Time, Standard Time, or Winter Time, that is in force for that time zone during the date and time specified by 'timestamp'. For example, 'Europe/London' represents UTC in the winter and UTC+1 in the summer.
As far as the "...based on the zip code" part of your question, understand that not every ZIP code is locality-based. There are also technical assignments, overseas APO/FPO addresses, US territories, and other edge cases. Additionally, some zip codes may straddle more than one time zone.
A better approach, when possible, is to:
Get an approximation of latitude/longitude coordinates - using a variety of techniques depending on your source data. For example, geocoding APIs can take a street address and give a lat/lon.
Then determine the time zone identifier for that location, using one of the techniques listed here.
I am building a website which will be viewed in UK, USA, and Europe, and want to know the best short date format to use.
I have been reading http://www.w3.org/QA/Tips/iso-date which reads...
*The international format defined by ISO (ISO 8601) tries to address all these problems by defining a numerical date system as follows:
YYYY-MM-DD where YYYY is the year [all the digits, i.e. 2012]
MM is the month [01 (January) to 12 (December)]
DD is the day [01 to 31]
For example, "3rd of April 2002", in this international format is written:
2002-04-03.*
...but still think that leaves room for error. The best I have seen is the BBC website uses "Thursday, 30 July" for example. Any suggestions?
Also, are there any Wordpress plugins that will handle this for me?
Ive used this plugin before https://wordpress.org/plugins/date-and-time-widget/screenshots/ which worked well (site is down now).
I agree with Zdeněk Šimůnek that you don't need the year. This plugin caters for all outputs really well.
If you want to manually add it with php, this is a good tutorial http://www.cyberciti.biz/faq/howto-finding-current-date-time-in-php/.
The BBC style is by me the best. If you were to write the month in number you would come to situation, where viewers in Europe would think that its for example 1st of February and in USA 2nd of January. Year is not needed as almost everybody knows what year it is. The day of the week is optional.
PS.: Many sites also writes a name day for current datum.
I want to know if there can be 2 or more GMT timezones for one city or state. I know there can be more then one GMT timezone for a country, but not sure if it's for state and city too. Share your knowledge please.
Interpreting the question to mean 'are there any cities which are in more than one time zone', then the answer is 'yes'. And there are American states with multiple time zones (Indiana and Arizona being two of them).
There has been recent discussion on the TZ mailing list about the area of China known as Xinjiang, which has a mixed population of Han Chinese and of Uyghurs. It seems that the Han use the standard Chinese time zone (Asia/Beijing), but the Uyghurs often use a local time zone. This is now encapsulated in the Olson database, with the name Asia/Urumqi for the Uyghur time zone.
So, for example, the zone.tab file in tzdata2010b.tar.gz, available from ftp://elsie.nci.nih.gov/pub/tzdata2010b.tar.gz (the code is ftp://elsie.nci.nih.gov/pub/tzcode2009t.tar.gz). There is an extensive description of how and why the change was made in the asia file.
Note that the Olson (Time Zone) database is now (2016-09-19) available from IANA at https://www.iana.org/time-zones rather than from NIH. You can get the current release easily enough; getting historical releases may be harder.
Yes, time zones really do change 20 times a year around the world, and sometimes at essentially no notice (that is, the government legislates the changes only a day or two before the change).
#basit asks:
Wow about the 20 times a year around the world. I'm trying to log the timezone for latitude and longitude, so now my question would be, how long should I log the data for? 6 months? 1 month? 2.. 3..?
And also, how long does it take for daylight savings to change in a year, because I need to log timezone with daylight saving and refresh the data after certain given period.
What I mean is that during the course of 2009, there were 20 issues of the time zone database, because of changes in rules in at least that many places. However, any given country usually only changes their rules once - though with Argentina, different states were changing their rules at different times and compounding the problems.
I'm not clear that we have enough information to tell you how long to log the data for. I'd be inclined to say at least 12 months, but it depends what you are going to do with it. At one level, all you need to do is keep up with the Olson database - that will tell you the time zone rules for essentially everywhere in the world. If you are interested in tracking the time zones of your visitors, then you can keep the data for as long as you like. Since not everyone uses the canonical Continent/City notation for their time zone (I tend to use the older US/Pacific notation, for instance - which is still supported, but is equivalent to America/Los_Angeles). The classical notations such as TZ=EST5EDT are ambiguous; both the USA and Australia have timezones that use EST as an abbreviation, and the dates when the switch between standard and daylight saving time occurs varies (witness the mass of data in the Olson database).
You also ask 'how long does it take for a time zone to change'. I'm not sure what you mean. In terms of 'when the clocks change (between standard and daylight saving time)', it is 'instantaneous'; one second it is one time zone offset; the next second it is the other. If you mean 'how long does it take for governments to change their mind', it varies radically. For example, both Europe and the USA have relatively fixed rules that change every few years; the rule in the USA had been stable for about 20 years, then they changed the rules about 3 years ago. Europe is similar. On the other hand, some countries change their rules yearly. My impression is that some of the Islamic countries adjust when they switch between standard and daylight saving time (or vice versa) depending in part on when Ramadan falls - if the change would occur during Ramadan, then they bring it forward, or delay it, so that the rule does not change during Ramadan. Other countries have different reasons for the brinksmanship that goes on - maybe it is the political equivalent of a release deadline. So it may take quite a while for people to decide what the 'final' (meaning 'next edition') of the rules will be for a given year.
The web site http://worldtimezone.com/ does a pretty good job of keeping track of most of these idiosyncracies.
I think you mean "Can one city or state span two time zones?". Yes. Mexico Beach, FL sits on the border between CST and EST with parts of the town in both time zones.
As for how you could tell a computer that, no idea.
There is only one gmt for the whole world. As for timezones, see here, showing variation of observance e.g. within Kansas.
Any arbitrary jurisdiction may have multiple timezones, though the majority do not.
Have a look at http://www.worldtimezone.com/faq.html