Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
timeDate stores some US holidays in GMT time zone. Given that the difference between GMT and US time zones differs throughout the year due to daylight savings, US holidays should not be stored in GMT time zone.
EST = GMT - 5 while not in daylight savings
EST = GMT - 4 from 2nd Sunday of March to 1st Sunday of November. (aka EDT)
This could bring some issues. For example:
library(timeDate)
holidayEIA <- function(x){ c(holidayNYSE(x),
USColumbusDay(x)#Data,
USVeteransDay(x)#Data)}
HolidaysEIA <- holidayEIA (2015)
#Output:
NewYork
[1] [2015-01-01 00:00:00] [2015-01-19 00:00:00] [2015-02-16 00:00:00]
[4] [2015-04-03 00:00:00] [2015-05-25 00:00:00] [2015-07-03 00:00:00]
[7] [2015-09-07 00:00:00] [2015-11-26 00:00:00] [2015-12-25 00:00:00]
[10] [2015-10-11 20:00:00] [2015-11-10 19:00:00]
Here holidayNYSE is in EST/EDT time zone, while USColumbusDay and USVeteransDay are in GMT time zone. Have to do the following to equalize:
library(timeDate)
holidayEIA <- function(x){ c(holidayNYSE(x),
USColumbusDay(x)#Data+ 14400,
USVeteransDay(x)#Data+ 18000)}
HolidaysEIA <- holidayEIA (2015)
#Output
NewYork
[1] [2015-01-01] [2015-01-19] [2015-02-16] [2015-04-03] [2015-05-25]
[6] [2015-07-03] [2015-09-07] [2015-11-26] [2015-12-25] [2015-10-12]
[11] [2015-11-11]
This is not really a question, yet given SO is a Q&A site, allow me phrase it as one. Wouldn't you agree that timeDate should store holidays in local time zones, as well as store all holidays for each country under the same time zone?
I don't work a whole lot with R, but I'll address this part of your question:
Wouldn't you agree that timeDate should store holidays in local time zones, as well as store all holidays for each country under the same time zone?
No. Fundamentally, holidays should not belong to a local time zone, nor to GMT, nor to any other time zone. In the vast majority of cases, an occurrence of a holiday is simply a calendar date, consisting of year, month, and date.
Storing it with times in a local time zone wouldn't make sense when a holiday is observed in a country with multiple time zones (like the US). Likewise, it wouldn't make sense for a holiday like Christmas Day or New Year's Day that is observed by many different people around the world.
However, when a particular individual observes a holiday, then you can take the current time zone of that individual, apply it to the calendar date, and compute the time for the start of the day, and the start of the next day. Together, those values form a half-open interval [start, end) describing how the local "day" maps to universal time.
Keep in mind that not all local days start at midnight. Some time zones have DST transitions that exclude the midnight hour, having a spring-forward from 23:59:59 to 01:00:00.
Consider the following example:
October 15th, 2017 in Brazil is the "Teacher's Day" holiday (per this list).
It also happens to be the scheduled date of the spring-forward transition (as shown here).
Stored in data, it should simply be a date: 2017-10-15.
When observed by a particular person, you take into account their time zone.
Brazil has multiple time zones, with standard time offsets ranging from UTC-2 to UTC-5 (see Wikipedia for details). Additionally, some of them observe DST and some do not.
So Teacher's day in 2017 in São Paulo is [2017-10-15T01:00-02:00, 2017-10-16T00:00-02:00), while the same holiday in Manaus is [2017-10-15T00:00-04:00, 2017-10-16T00:00-04:00).
Normalized to UTC, that's [2017-10-15T03:00Z, 2017-10-16T02:00Z) in São Paulo, but in Manaus it's [2017-10-15T04:00Z, 2017-10-16T04:00Z).
From this we can see that the concept of a "day" is not the same for everyone, neither in terms of absolute start and end, nor in terms of duration.
Related
I have a dataset with intraday data where three important variables are Country, Datetime, Price.
An example could be:
Sweden, 2019-12-23 09:08:00, 105.31
This data is downloaded from Bloomberg, and it looks like it uses my local time (Denmark). For example, for Australia I have a market which starts at 23 00 which does not make sense unless it is European time. I would like to convert the time that I have in the data to the local time in that particular country. Of course, I could add or subtract some hours, but the time difference is not fixed: some countries have summer/winter time while other countries don't, and countries which do have summer/winter time may change on different days (for example I think there is about one week between the time change in US and Europe). Do you have an advice how to transform my dataset into the local timezone? So, if it says "2019-12-23 09:08:00", then I would like to know that in that particular country it was 09:08 in the morning (and not in my country). I really hope there is a smart R function for this.
Thanks in advance!
You could use lubridate::force_tz and lubridate::with_tz:
dat <- as.POSIXct("2021-05-01 12:00:00",tz = "UTC")
lubridate::force_tz(dat,tz="CET")
#> [1] "2021-05-01 12:00:00 CEST"
lubridate::with_tz(lubridate::force_tz(dat,tz="UTC"))
#> [1] "2021-05-01 14:00:00 CEST"
I am working with financial asset pricing data and I am interested in finding the time difference between the dates of two consecutive operations on the market.
A simple example could be:
first operation -> client X buys stock A on 2020-01-02 09:00:00
second operation -> client X buys stock B on 2020-01-03 09:00:00
Here is my problem:
I am looking for a function that computes the FINANCIAL time difference between this two datetime objects.
Hence, I am not interested in a simple calendar time difference (that can be computed in R using the well-known difftime() function), but in a time difference that considers the financial or trading day, that is (roughly speaking) a day that starts at 9.00 am and ends at 18.00 pm.
Therefore, this function should give a result of 9 hours (if the unit reference is hour) to the simple example above, instead of 24 hours as the usual calendar time difference would suggest.
A more complex version of this function would also take into account the market holidays and exclude weekends from computation.
Following an example using R
d1 <- as.POSIXct("2020-01-02 09:00:00", tz = "UTC")
d2 <- as.POSIXct("2020-01-03 09:00:00", tz = "UTC")
difftime(d2, d1, units = "hours")
This produce a time difference of 24 hours.
However, the expected result would be just 9 hours, since the financial (or market trading) day ends on 2020-01-02 at 18.00 pm and starts again the day after at 9.00 am, hence there should be only 9 hours of trading between the two.
I mainly work in R, so I would appreciate if someone can give me some advice on that language, but if anyone knows something similar in other languages would also be very useful.
Thank you a lot for your help and time.
As you can see the question above, I was wondering if IDL is able to add or subtract days / months / years to a given date.
For example:
given_date = anytim('01-jan-2000')
print, given_date
1-Jan-2000 00:00:00.000
When I would add 2 weeks to the given_date, then this date should appear:
15-Jan-2000 00:00:00.000
I was already looking for a solution for this problem, but I unfortunately couldn't find any solution.
Note:
I am using a normal calendar date, not the julian date.
Are you only concerned with dates after 1582? Is accuracy to the second important?
The ANYTIM routine is not part of the IDL distribution. Possibly there are third party routines to handle time increments, but I don't know of any builtin to the IDL library.
By default, which you are using, ANYTIM returns seconds from Jan 1, 1979. So to add/subtract some number of days, weeks, or years, you could calculate the number of seconds in the time interval. Of course, this does not take into account leap seconds/years (but leap years are fairly easy to take into account, leap seconds requires a database of when they were added). And adding months is going to require determining which month so to determine the number of days in it.
IDL can convert to and from Julian dates using JULDAY and CALDAT.
You may also read and write Julian dates (which are doubles or long integers) to and from strings using the format keyword to PRINT, STRING, and READS.
You'll want to use the (C()) calendar date format code.
format='(c(cdi0,"-",cMoa,"-"cyi04," ",cHi02,":",cmi02,":",csf06.3))'
date = julday(1, 1, 2000)
print, date, format=format
; 1-Jan-2000 00:00:00.000
date = date + 14
print, date, format=format
; 15-Jan-2000 00:00:00.000
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have integers like the following:
41764 41764 42634 42634 42445 42445 41792 41807 41813 41842 41838 41848 41849 41837
Which need to be converted into date, the time doesn't matter.
I'm told that when it's converted it should be in the year 2014, current conversions I've tried have either given the year as 1984 or 2084.
Thanks!
Sam Firke's janitor package includes a function for cleaning up this Excel mess:
x <- c(41764L, 41764L, 42634L, 42634L, 42445L, 42445L, 41792L, 41807L,
41813L, 41842L, 41838L, 41848L, 41849L, 41837L)
janitor::excel_numeric_to_date(x)
## [1] "2014-05-05" "2014-05-05" "2016-09-21" "2016-09-21" "2016-03-16" "2016-03-16" "2014-06-02"
## [8] "2014-06-17" "2014-06-23" "2014-07-22" "2014-07-18" "2014-07-28" "2014-07-29" "2014-07-17"
Excel reader functions likely take care of this for you, which would be the best approach.
I assume your have Excel date integers here. Microsoft Office Excel stores dates as sequential numbers that are called serial values. For example, in Microsoft Office Excel for Windows, January 1, 1900 is serial number 1, and January 1, 2008 is serial number 39448 because it is 39,448 days after January 1, 1900.
Please note Excel incorrectly assumes that the year 1900 is a leap year. No problem when calculating today only.
Microsoft Excel correctly handles all other leap years, including century years that are not leap years (for example, 2100). Only the year 1900 is incorrectly handled.
See Microsoft Knowledge Base for further information.
There is a offset of two days between the R script proposed by #loki and a calculation in Excel.
Please read following date conversion help documents (snippet see below):
## date given as number of days since 1900-01-01 (a date in 1989)
as.Date(32768, origin = "1900-01-01")
## Excel is said to use 1900-01-01 as day 1 (Windows default) or
## 1904-01-01 as day 0 (Mac default), but this is complicated by Excel
## incorrectly treating 1900 as a leap year.
## So for dates (post-1901) from Windows Excel
as.Date(35981, origin = "1899-12-30") # 1998-07-05
## and Mac Excel
as.Date(34519, origin = "1904-01-01") # 1998-07-05
## (these values come from http://support.microsoft.com/kb/214330)
use as.Date() as #MFR pointed out. However, use the origin 1900-01-01
x <- c(41764, 41764, 42634, 42634, 42445, 42445, 41792, 41807,
41813, 41842, 41838, 41848, 41849, 41837)
as.POSIXct.as.Date(x, origin = "1900-01-01")
# [1] "2014-05-07" "2014-05-07" "2016-09-23" "2016-09-23" "2016-03-18"
# [6] "2016-03-18" "2014-06-04" "2014-06-19" "2014-06-25" "2014-07-24"
# [11] "2014-07-20" "2014-07-30" "2014-07-31" "2014-07-19"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
Am I crazy, I've always thought there were 52 weeks in a year, a check on google returns numerous results stating the same...
But if I create a simple spreadsheet, with column A containing 1 to 365 and column B containing INT(A1 / 7) repeated 365 times, column B contains the week index corresponding to the 'julian' day in column A.
The weeks go from 0 to 52, this is actually 53 weeks. If the 1st of January is on day 0, then the 31st of December must overlay into week 1 of the next year.
Can some help explain why we say 52 weeks and not 53?
Sorry I know this isn't strictly a coding question, but is is very relative to a lot of problems with dates and coding.
There are 52 complete weeks in a year. The year has 365 days, leaving one extra day. A leap year has 366 days, adding a second extra day. This makes 52 1/7 weeks in a normal year and 52 2/7 weeks in a leap year..
An ISO week-numbering year (also called ISO year informally) has 52 or 53 full weeks, that is 364 or 371 days instead of the usual 365 or 366 days. The extra week is sometimes referred to as a leap week, although ISO 8601 does not use this term.
The ISO week date system is effectively a leap week calendar system that is part of the ISO 8601 date and time standard issued by the (ISO) since 1988 and, before that, it was defined in ISO (R) 2015 since 1971. It is used (mainly) in government and business for fiscal years, as well as in timekeeping. This was previously known as "Industrial date coding". The system specifies a week year atop the Gregorian calendar by defining a notation for ordinal weeks of the year.
Weeks start with Monday. Each week's year is the Gregorian year in which the Thursday falls. The first week of the year, hence, always contains 4 January. ISO week year numbering therefore slightly deviates from the Gregorian for some days close to 1 January.