Great talk, thanks! You didn't cover one issue that causes many problems in PIM calendar systems: A day (e.g. an "all-day" event) can have two very different meanings. a) My birthday (or Christmas, or pi day, or ...) is from midnight to midnight on a particular calendar date.. If I travel to a different timezone, I don't want my calendar showing me that my birthday is from 7am today until 7am tomorrow. But, b) An all-day event in London occurs during a definite 24-hour period. If I watch a live-stream of the event while i'm in NY, I need to start watching at 7pm the previous night. I know that Microsoft Exchange gets this very wrong. It treats all user-entered events as "type b" (ranges of time instances). I don't know of any systems that do correctly support both kinds of ranges with a reasonable user interface for each.
There's another 'period' that is used a lot and is very easy to get wrong: number of business days. Debt collectors use this, where they say you have an x amount of business days to pay. Now you all of the sudden deal with localized holidays. We deal with something like that. And just to make it extra fun, our country has an official holiday that is only a holiday if the year is mod 5.
Can't wait to try this out on my broken code and see what can be turned around. Noda Time is definitely on our wish list for dealing with cross tech-stack and platform date time exchange. Wonderful presentation as always #jonskeetfan
I think the best thing is to remove the concept of months, and stick to year, week, day of week, hours (24), minutes, seconds, etc., Because now would be 2019.44.5T13:57:22UTC
John- you lost me at 30:35. You said we wouldn't know what time it would be a minute later since the -8:00 wasn't a time zone. I don't understand this. Why wouldn't the given information be enough? (2017-01-19T09:01:00-08:00 isn't correct lol?)
I'm not Jon, but the reason why it wouldn't be enough is because you don't know which time zone, and therefore which daylight savings time rules, that time is from. In the case of January 19th you can be safe in assuming that a minute later will be 2017-01-19T09:01:00-08:00. But what if that date was 2017-10-29T01:59:00-05:00? What would the time be one minute later? The correct answer is "I don't know", because I **haven't given you enough information** to answer the question! The missing piece of information is "What country are you in?" If you're in the USA, where daylight savings time ends on November 5th in 2017, then the time one minute later will be 2017-10-29T02:00:00-05:00. But if you're in **Mexico**, where daylight savings time ends on October 29th in 2017, then the correct answer would instead be 2017-10-29T01:00:00-06:00. And that's why a simple numeric offset isn't enough information: you need to know the actual time zone, including the geographical region, so that you know what the daylight savings time rules are for *that* region.
why don't we just add a second 32 bit unsigned number which tells us what epoch we're in? epoch 0 is the 1970 epoch, epoch 1 is the 2038 epoch or whatever, and so on.. it's just 32 more bytes, and AS IF we're going to be alive long enough to reach year 146028888064
Great talk, thanks!
You didn't cover one issue that causes many problems in PIM calendar systems: A day (e.g. an "all-day" event) can have two very different meanings.
a) My birthday (or Christmas, or pi day, or ...) is from midnight to midnight on a particular calendar date.. If I travel to a different timezone, I don't want my calendar showing me that my birthday is from 7am today until 7am tomorrow. But,
b) An all-day event in London occurs during a definite 24-hour period. If I watch a live-stream of the event while i'm in NY, I need to start watching at 7pm the previous night.
I know that Microsoft Exchange gets this very wrong. It treats all user-entered events as "type b" (ranges of time instances). I don't know of any systems that do correctly support both kinds of ranges with a reasonable user interface for each.
It's a good thing that he chose not to predict what would happen in 2020, he would surely have been wrong.
And it staid...at least for a bit
There's another 'period' that is used a lot and is very easy to get wrong: number of business days. Debt collectors use this, where they say you have an x amount of business days to pay. Now you all of the sudden deal with localized holidays. We deal with something like that. And just to make it extra fun, our country has an official holiday that is only a holiday if the year is mod 5.
"don't write your own date and time library" says the man who wrote his own date and time library. And he is right.
Can't wait to try this out on my broken code and see what can be turned around. Noda Time is definitely on our wish list for dealing with cross tech-stack and platform date time exchange.
Wonderful presentation as always #jonskeetfan
I think the best thing is to remove the concept of months, and stick to year, week, day of week, hours (24), minutes, seconds, etc., Because now would be 2019.44.5T13:57:22UTC
John- you lost me at 30:35. You said we wouldn't know what time it would be a minute later since the -8:00 wasn't a time zone. I don't understand this. Why wouldn't the given information be enough? (2017-01-19T09:01:00-08:00 isn't correct lol?)
I'm not Jon, but the reason why it wouldn't be enough is because you don't know which time zone, and therefore which daylight savings time rules, that time is from. In the case of January 19th you can be safe in assuming that a minute later will be 2017-01-19T09:01:00-08:00. But what if that date was 2017-10-29T01:59:00-05:00? What would the time be one minute later? The correct answer is "I don't know", because I **haven't given you enough information** to answer the question! The missing piece of information is "What country are you in?" If you're in the USA, where daylight savings time ends on November 5th in 2017, then the time one minute later will be 2017-10-29T02:00:00-05:00. But if you're in **Mexico**, where daylight savings time ends on October 29th in 2017, then the correct answer would instead be 2017-10-29T01:00:00-06:00. And that's why a simple numeric offset isn't enough information: you need to know the actual time zone, including the geographical region, so that you know what the daylight savings time rules are for *that* region.
Great explanation. I understand now. I wish I could give you two thumbs up. Thanks!
why don't we just add a second 32 bit unsigned number which tells us what epoch we're in? epoch 0 is the 1970 epoch, epoch 1 is the 2038 epoch or whatever, and so on.. it's just 32 more bytes, and AS IF we're going to be alive long enough to reach year 146028888064
that just sounds like a 64-bit offset from 1970 epoch, since (1
What does an incel and Excel have in common? Mistakenly thinking something is a date!