Earlier quoted context omitted.
Why would anybody schedule events in local time to happen on leap seconds?
To make sure you covered those edge cases correctly!
The best coverage is not introducing special cases where they aren’t relevant.
UTC Is Enough for Everyone, Right?
261–270 of 321 posts
Re: UTC Is Enough for Everyone, Right?
#262Lost me at “rich, white railroad tycoons”. What on earth does skin colour have to do with anything in this article?
Re: UTC Is Enough for Everyone, Right?
#263Earlier quoted context omitted.
Another example of confusing user-intent is "last X days". I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.
"One month from now" is horrible. Is that "30 days from now" or "same day number next month"? If the latter, then how do you handle a 31st when the next month has 30 days or fewer? (Or a 29th when the next month is February and this is not a leap year?) This is a difficult subject. Recurrence is especially tough to model in a database.
How about adding the number of days in the current month?
Re: UTC Is Enough for Everyone, Right?
#264Great description of pains I've been feeling the last 5 years in my daily life. Just one comment on colors, I can read the whole post but when I switch or look somewhere else my eyes have a hard time adjusting to all those crazy colors I just saw. Maybe I'm broken.
Cone receptors saturate when you look at the same hue for a period of time and loose sensitivity for a while. It's known as retinal fatigue or cone fatigue and causes after images. It's normal and used in several optical illusions.
Re: UTC Is Enough for Everyone, Right?
#265So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
Time is difficult and system design depends on the intended consumer. For the case you propose, I read it as a "meeting" planned at a point in the future. In this case storing the start of the meeting as a bare timestamp is inappropriate design. What really should be encoded is the set of rules for identifying the proper timestamp. There was an existing standard mentioned for that which I'd use as a starting point if…
Thank you. There seems to be some serious overdesign in the original article and a many of the follow up comments. Design should follow specific classes of user’s goals and intent, not an attempt to craft a universal solution for everyone, across all time.
Form follows function. If the concept of “10 AM on Saturday” is important to your users, model the software in line with that domain knowledge. All problems are bounded by context, and knowing the boundaries makes designs simplier and easier to manage.
Re: UTC Is Enough for Everyone, Right?
#266So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
IMO the biggest problem isn't the how you store information or even do the date-math. The most frustrating thing is drawing out user-intent, distinguishing between two use-cases which are so similar that most users won't even know what they want. Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged t…
Normalizing temporal expressions, that is, putting human language onto a strict timeline, is a hard problem in natural language processing. There's some literature on it, which may or may not be helpful, at least in establishing the most likely intent.
Re: UTC Is Enough for Everyone, Right?
#267So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
That's what we do in the Cyrus IMAP scheduler for future alarms. We set the trigger at most 30 days in the future, and at that point it will re-calculate when the alarm should fire. Using the tz database at the time each time around.
Of course, calendar events in icalendar have the tzdata stored along with them, in theory, so they should never change unless your client updates them. Which leads to its own world of fun.
Re: UTC Is Enough for Everyone, Right?
#268> Properly storing timezone-aware times I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MyS…
You're confusing time zone with UTC offset. The two are not the same concept. You can determine a UTC offset given a time zone ID and a date/time but the opposite is not necessarily true. A time zone ID cannot be reliably discovered given only its UTC offset; the mapping is not unique.
Yeah! We work around that in our logic at FastMail by choosing the largest population area which exactly matches the tzmapping data (generally it's from an icalendar file with some weird name and some rules which show the next couple of timezone transtions)
It's ugly and horrible, but that's life.
Re: UTC Is Enough for Everyone, Right?
#269One thing I’d love to know is how the heck as software devs will we manage a future moon or Martian colony with its own set of discrete time zones...
Admittedly you can’t schedule a phone call or chat since the latency is too great but if you wanted to schedule an event to occur in say a software system on both planetary bodies at the same time your software or time library would need awareness of celestial mechanics...sounds like a fun problem :)
Re: UTC Is Enough for Everyone, Right?
#270Earlier quoted context omitted.
We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…
This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or ano…
I've generally decided to just avoid scheduling calls for the working week before and after the DST switchover, because I never remember which of the UK and US switches first, and in which direction, and so many other people mess it up too. Of course, not everyone has that luxury of avoiding calls...