The true meaning of _time("B")

[MindprisM]

I have been using _time("B") to make a lot of GUIDs. Now I need to get the date out of that value. Can anyone show me how to decompose that number? I had (evidently mistakenly) thought it was the milliseconds since Epoc.

As a string it is '7717310053055349' for '2009-08-19 10:44:15', and playing around with it I see there are at least two numbers in there, one to the left of 00 and one to the right.

I need a solution that doesn't rely on Slickedit built-ins, in other words psuedo-code or a specification.

TIA

[Graeme]

So what do you get if you get the value from _time('b') for today and subtract 7717310053055349.  Do you get 21 or 22 days? i.e. if you divide the difference by 86,400,000 do you get 21 or 22.  If so, you could get the date by working backwards from the current date and _time('b') values.  The latest version of slick includes a guid generator.

Graeme

edit - on my machine, _time('b') is currently giving me 10289050075311859

[MindprisM]

Code: [Select]

Note col:       *
My first part:  771753
Ur First part: 1028905

I am GMT -5 (EST)
are you GMT -8  (PST)?


My Experiments
===============
I made these by moving clock back and forth and the following function:

_command void timeb_test() name_info(',')
{
   _str s=_time("B") ' '_date('U')' '_time('M');
   insert_line(s);

}


Items

1) hour change - RR is rollover  |result:wierd, inconclusive
        86400000??
7717530084382046 9/9/2009 19:26:22
    +1  RR                +1
7717540001702468 9/9/2009 20:28:22


2) day change |result:decrements day part, good
7717530084382046 9/9/2009 19:26:22
    -1            -1
7717520084590671 9/8/2009 19:29:50

3) month change |result:decrements day part, good
7717530085156703 9/9/2009 19:39:16
   -31          -1
7717210085172375 8/9/2009 19:39:32

4) year change 1 year |result:decrements by funny number, inconclusive
7717530085254921 9/9/2009 19:40:54
  -384                 -1
7713690085266468 9/9/2008 19:41:06


5) year change 2 year |result:same as #4, inconclusive
7717530085463546 9/9/2009 19:44:23
  -768                 -2
7709850085478031 9/9/2007 19:44:38

6) hour change |result:ok
7717530085717484 9/9/2009 19:48:37
        -3589313          -1
7717530082128171 9/9/2009 18:48:48


7) hour change |result:wierd again, inconclusive
7717530085929546 9/9/2009 19:52:09
    +1  RR                +1
7717540003138109 9/9/2009 20:52:18



Summary:
Going forward an hour gives unexpected rollovers, going back and hour is ok.
Tentative conclusion - _time("B") is GMT -0, so at 20:00:00 EST time is 00:00:00 GMT (off by one because of Daylight savings)


9/9/2009 - 71753 days is March 28, 1813
9/9/2009 -  1753 days is November 21, 2004


Almost there, any ideas?



[MindprisM]

Inline documentation says:
_time('b')

Return binary time in milliseconds.  This options is used for comparing dates with the :< and :> operators.

Not quite.

[Graeme]

I'm GMT + 12 - New Zealand.

[Graeme]

Almost there, any ideas?

Nope, not really, except that I'm not sure why you say going forward gives unexpected rollover because as you say, the value is two separate numbers and the value 84382046 rolls over at 86,400,000 as you wrote.

What's puzzling is that slick c code uses the _time('b') value to calculate elapsed times in places e.g. in _as_heartbeat.  This will get the wrong result across the 86,400,000 rollover  -  presumably midnight somewhere.

If the code is already assuming that elapsed time doesn't work across day boundaries, perhaps the 384 comes from assuming there are 32 days in every month instead of looking up the exact number of days in a month and dealing with leap years etc.  I don't feel like fiddling with my clock but I wonder what you get when you compare 5 minutes to midnight on 31 december with 5 minutes past midnight the next day.  The result should be 10*60*1000 = 600,000.

Graeme

[Lee]

time('B') option returns a string, calculated from GetSystemTime() (on Windows):

"year*32*16 + month*32 + day"  +
"hours * 60 * 60 *  1000 +  minutes * 60 * 1000 + millisecs", with leading zero padded to 10 digits on the H:M:MS part.

[MindprisM]

Thanks for your reply Lee, but:

Code: [Select]

Graeme gets 10289050075311859 on about September 09, 2009, 05:54:34 PM
And I get    7717550024499281 9/11/2009 02:48:19

"year*32*16 + month*32 + day"  +
"hours * 60 * 60 *  1000 +  minutes * 60 * 1000 + millisecs",

gives -

2009*32*16=1028608
9*32      =    288
11        =     11
          =1028907 for the ymd part (so Graeme is good)

my ymd    = 771755 (double plus ungood)

so why am I so low

working backwards

771755-11d    =771744
771744-9m*32  =771456
771456/(32*16)=  1506.75  (Im living in the 1500s)

<cue twilight zone music>

SlickEdit Version 12.0.3.0
Build Date: September 20, 2007
Emulation: CUA

OS: Windows XP
Version: 5.01.2600  Service Pack 2

[chrisant]

The internal format of _time('b') is not documented, and the only guarantee is that the values will be suitable for comparison.  There's no guarantee about persisting them across sessions or versions, or that the format will never change, etc.

Perhaps the internal format has changed since SE 12.0.3.

Anyway, this is trying to use something in a way that it was not designed for and which is outside of its documented guarantees.

[Graeme]

I was thinking of mentioning what Chrisant said but figured you'd already realised that and perhaps have some guid you still need to decode.

Anyway

2009*32*16=1028608
9*32      =    288
11        =     11

my ymd    = 771755 (double plus ungood)

Working backwards
771755 - 11 = 771744
771744 - (9*32) = 771456
771456/2009 = 384

384 = 32*12

So it's probably year*32*12 instead of year*32*16 for slick 12.0.3

In slick 12.0.3 I also get 771755 for Sept 11 2009.

Graeme

[Lee]

Spot on Graeme, +1.  I spoke from the current source obviously, dialing back into the source control time machine I see that the string generator for that changed prior to shipping v14. It used "year*32*12 + month*32 + day" in the leading part of the string.  Minor flaw is that it adds a carry to the year part if the month is 12, affecting calculations.  Changing it to 16 now makes it look like:  year << 9 | month << 5 | day, binary-wise.

If you really need a GUID generator, it is possible to write your own DLL interface to export custom commands.  That way you could invoke CoCreateGUID or UuidCreate directly and format and insert it however you choose.  In the samples directory in the shipped version of SlickEdit (samples\simple) that has a overly simplified example that should get you started.

[MindprisM]

Applause !