[Opa] timezones

Adam Koprowski Adam.Koprowski at mlstate.com
Mon Feb 6 17:52:23 UTC 2012


  Hey guys,

  Thanks for your interest and help with getting Opa's handling of time
zones on track! We just merged Alok's patch and I just added a
Date.now_gmt() function that Owen was suggesting. In fact I first
implemented:
now_at( {at_client} or {at_server} or {calling_site} location
      , {local_timezone} or {GMT} timezone
      ) : Date.date
(I hope the semantics is clear) but then I hit a dependency nightmare in
the standard library, so had to step back to a simpler Date.now_gmt() --
having that and Date.now() it's easy enough to implement functionality of
the above function.

  With this patch in place (Opa v. 1242 and above, I believe) one can
compile the following program:

server function now_gmt_server() { Date.now_gmt() }
client function now_gmt_client() { Date.now_gmt() }
server function now_local_server() { Date.now() }
client function now_local_client() { Date.now() }

function now() {
  function show(f) { Date.to_debug_string(f()) }
  <div>GMT server: {show(now_gmt_server)}</>
  <div>GMT client: {show(now_gmt_client)}</>
  <div>local server: {show(now_local_server)}</>
  <div>local client: {show(now_local_client)}</>
}

function page() {
  <span onready={function (_) { #Body = now()}} />
}

Server.start(Server.http, {title: "Now", ~page})

 and I just run it getting:

GMT server: 2012-02-06 | 17:29:14.234
GMT client: 2012-02-06 | 17:24:34.177
local server: 2012-02-06 | 18:29:14.290
local client: 2012-02-06 | 18:24:34.222

in response.

  Concerning longer term support for time zones in Opa my plan was to:

   1. Introduce Timezone module and Timezone.timezone type -- most likely
   it should be represented by an abstract integer (offset in minutes from
   GMT). Having some kind of enumeration type for (most popular?) time zones
   would also be useful, but this seems to be a tricky issue... any good
   reference for that? some programming language that does that neatly? I'd
   rather not over-complicate things with summer times, leap seconds ans such,
   just yet.
   2. Introduce a type for timezone-aware date (good name, anyone?) which
   will essentially be a pair: GMT time + Timezone.timezone
   3. Introduce conversion functions between times in different time-zones.

  How does that sound? Any suggestions?
  Since with what we have now one can reasonably work with dates&times, I
cannot promise I'll give this work the highest priority, though :/.

  Best,
  Adam

On Sun, Feb 5, 2012 at 20:51, Owen Gunden <ogunden at phauna.org> wrote:

> On Sat, Feb 4, 2012 at 7:05 PM, Alok Menghrajani <alok at fb.com> wrote:
> > It's weird, I have not been getting all the emails from the list :(
> >
> > Owen: I have a pull request that adds basic timezone support
> > (https://github.com/MLstate/opalang/pull/34).
>
> Hey, awesome, I can definitely work with this.
>
> > While I'm working to get this merged, feel free to look at it and let me
> > know if it fits your needs?
>
> Actually you've just demonstrated the existence of Unix.gmtime in
> ocaml; if there were an equivalent of Time.now() but with gmt
> (Time.now_gmt()) that used gmtime underneath that would make what I'm
> doing really simple. I'm not sure if this fits into whatever timezone
> interface the Opa guys had in mind though. Maybe Adam can chime in?
>


> _______________________________________________
> Opa mailing list
> Opa at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/opa
>



-- 
*Adam Koprowski                [http://adam-koprowski.net]
Opa Tech Evangelist @ MLstate [http://opalang.org | http://mlstate.com]*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/opa/attachments/20120206/c9f0f253/attachment.html>


More information about the Opa mailing list