On Sun, Mar 10, 2013 at 4:59 PM, Jim Monty <[email protected]> wrote:
> > I believe this is how you might represent the RELATIVE time noon in > Caracas on October 12, 2018 using the iCalendar standard: > > DTSTART;TZID=America/Caracas:20181012T120000 > So, to compare that to some point in time (e.g. now() ) it must be turned into, well, a point in time like UTC based on what it knows about timezones -- at the moment. It's imposible to know what point in time that is until it actually happens, right? It's politics. Hard to imagine storing that form in a database and doing queries where offset calculations must be done at the time a query is run. Seems very expensive. > > The iCalendar standard specifies how to handle daylight/standard time > boundary cases such as when the same time occurs twice on the same day, > or when a time doesn't occur on a transitional day—like today in most > of the United States! > You know, yesterday I got curious and set both my Android phone and my wife's iPhone for a 2:30am alarm. I was curious when it would go off. Unfortunately, I told my wife about this and the experiment was quickly called off. -- Bill Moseley [email protected]
